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EXECUTIVE  SUMMARY 


This  specification  establishes  design  criteria  for  an  Airspace  Probe 
algoritha,  part  of  the  Initial  automation  for  the  advanced  automa¬ 
tion  system  of  the  Federal  Aviation  Administration's  (FAA's)  Air 
Traffic  Control  (ATC)  system.  The  algorithm  provides  data  to 
construct  a  message  to  air  traffic  controllers  when  an  aircraft  is 
predicted  to  get  too  close  to  terrain  or  other  areas  wherein  flight 
is  restricted. 

Airspace  Probe  Is  designed  to  be  compatible  with  current  air  traffic 
control  procedures  and  Its  design  Is  an  extension  of  the  En route 
Minimum  Safe  Altitude  Warning  function  of  NAS  Stage  A.  Airspace 
Probe  extends  the  geographical  coverage  by  providing  a  warning  for 
controllers  If  an  aircraft  flight  plan  penetrates  Enroute  Minimum 
Safe  Altitude  Warning  areas  or  Special-Use  Airspaces.  Airspace 
Probe  also  extends  the  tine  over  which  a  warning  may  occur  by  using 
tiie  flight  plan  to  predict  penetrations. 

Airspace  Probe  algorithms  assume  that  each  airspace  area  is  repre¬ 
sented  by  a  polygonal  volume.  The  geographical  coordinates,  activa¬ 
tion  and  deactivation  times,  and  a  maximum  and  minima  altitude  have 
been  provided  by  adaptation  or  supervisor  Interaction.  After  boun¬ 
daries  are  defined,  the  Airspace  Probe  algorithm  automatically 
detects  penetrations  of  these  areas.  It  processes  aircraft  trajec¬ 
tories  which  are  derived  from  ATC  approved  flight  plans  for  aircraft 
operating  within  an  Instrument  Flight  Rule  (IFR)  context.  The 
trajectory  is  checked  to  see  if  it  intersects  any  Enroute  Minimum 
Safe  Altitude  Warning  areas  or  Special-Use  Airspaces  in  the  Planning 
Region.  If  any  intersections  are  found,  data  describing  the  pene¬ 
trations  are  stored  in  the  data  base.  The  Airspace  Probe  is  invoked 
automatically  when  an  incoming  aircraft's  flight  plan  is  received  by 
a  center,  when  an  aircraft's  flight  plan  is  amended  and  when  flight 
plans  are  resynchronized.  When  any  of  these  things  occur,  trajec¬ 
tories  are  reprobed  to  account  for  the  change.  If  a  supervisor 
activates  and  deactivates  an  area,  the  trajectories  are  also 
reprobed  to  Incorporate  this  change. 
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1. _ INTRODUCTION 

The  Federal  Aviation  Administration  (FAA>  is  currently  in  the 
process  of  developing  a  new  coaputer  system,  called  the 
Advanced  Autonation  System  (AAS),  to  nelp  control  the  nation's 
air  traffic.  Tho  AAS  will  consist  of  new  or  enhanced  hardware 
(l.e.,  Central  Processing  Units,  memories,  and  terminals)  and 
new  software. 

The  new  software  will  retain  most  or  all  of  the  functions  in 
the  existing  National  Airspace  System  (NAS)  Eh  Route  Stage  A 
software.  The  algorithms  will  need  to  be  coded  and,  in  some 
cases,  revised.  In  addition,  the  new  AAS  software  will  contain 
several  new  functions  that  make  greater  use  of  the  capabilities 
of  automation  for  Air  Traffic  Control  (ATC).  When  fully 
implemented,  these  new  functions  are  intended  to  detect  and 
resolve  many  routine  ATC  problems. 

The  initial  implementation  of  the  AAS,  described  in  the  AAS 
Specification  [1],  will  provide  the  ability  to  detect  some 
common  ATC  problems.  To  meet  the  requirements  of  the  AAS, 
several  new  ATC  functions  need  to  be  postulated  and  described. 
Four  of  these  functions  are  described  in  this  document: 
Trajectory  Estimation,  Flight  Plan  Conflict  Probe,  Airspace 
Probe,  and  Sector  Workload  Probe  [Volumes  1,  2,  3,  and  4]. 
Together,  they  represent  an  initial  level  of  automation  and  the 
beginnings  of  the  evolution  of  the  ATC  system  in  accordance 
with  the  NAS  Plan  [2].  The  NAS  Plan  represents  an  overview  of 
the  complete  set  of  changes  proposed  to  NAS  in  the  coming 
decade. 

1.1  Purpose 

The  purpose  of  this  volume  is  to  identify  design  criteria  for 
Airspace  Probe.  Airspace  Probe  is  one  of  the  advanced  automa¬ 
tion  functions  called  for  in  the  AAS  Specification.  The  design 
criteria  specified  In  this  volume  are  based  on  the  existing  NAS 
and  the  specification  of  the  AAS.  The  AAS  specification 
describes  the  Airspace  Probe  function  and  proposed  some  high- 
level  requirements  for  this  function. 

1.2  Scope 

This  algorithmic  specification  presents  design  criteria  for  a 
computational  framework  of  Airspace  Probe.  The  framework  is  a 
set  of  algorithms  which  collectively  describe  how  it  may  be 
possible  to  detect  aircraft  that  are  in  danger  of  violating 
certain  separation  standards  with  given  airspace  volumes  where 
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normal  flight  Is  restricted.  It  may  be  viewed  as  a  candidate 
for  consideration  in  the  final  design.  However,  it  is  not 
intended  to  be  the  complete  final  design  for  Airspace  Probe  in 
the  AAS. 

The  framework  establishes  the  requirments  for  input  and  output 
data  and  provides  a  description  of  the  flow  of  control  of  data 
as  it  is  transferred  from  input  to  output.  Some  of  the  prin¬ 
cipal  requirements  have  been  identified  in  the  "Operational  and 
Functional  Description  of  AERA  1.01”  [3].  To  the  extent  pos¬ 
sible,  the  data  are  discussed  using  existing  NAS  terminology. 

1.3  Organisation  of  This  Document 

The  remainder  of  Section  1  provides  a  description  of  Airspace 
Probe's  role  in  the  larger  ATC  context  and  in  future  enhance¬ 
ments  of  the  ATC  System.  Both  the  operational  considerations 
and  processing  methods  of  Airspace  Probe  are  summarized.  Sec¬ 
tion  2  defines  the  terminology  used  in  the  specification  and 
discusses  the  factors  which  influence  the  design  of  the  algo¬ 
rithms. 

Descriptions  of  the  algorithms  are  contained  in  Section  3, 
Airspace  Probe  Functional  Design,  and  in  Section  4,  Detailed 
Description.  The  Airspace  Probe  function,  like  the  other 
advanced  automation  functions,  is  divided  hierarchically  (from 
top  to  bottom)  into  subfunctions,  components ,  and  elements 
(underlined  words  in  Sections  1  and  2  are  critical  to  the 
understanding  of  this  specification  and  their  definitions  can 
be  found  in  the  Glossary,  Appendix  D).  Section  3  specifies  the 
design,  environment,  and  assumptions  of  the  subfunctions  (e.g., 
the  First-Order  Coarse  Filter),  and  outlines  their  components 
(e.g.,  Grid  Chain  Generation).  Section  4  provides  a  detailed 
description  of  each  subf unction's  components,  including  their 
mission,  data  requirements,  and  processing  details,  and  in  some 
cases  includes  a  discussion  of  a  component's  elements. 

Appendix  A  defines  the  data  shared  by  the  various  subfunctions 
of  Airspace  Probe.  (Similarly,  Volume  5  of  this  document 
contains  the  global  data  shared  by  the  functions  defined  in 
Volumes  1  through  4.)  Appendix  B  provides  a  description  of 
several  elements  used  in  several  places  in  Section  4.  Appendix 
C  provides  mathematical  derivations  of  certain  formulas  used  in 
the  specification.  Supplementary  information  concerning  poly¬ 
gon  penetration  computations  is  provided.  Appendix  D,  as 
mentioned  above,  contains  a  glossary  of  those  terms  that  are 
critical  to  an  understanding  of  this  specification. 
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A  Program  Design  Language  (PDL)  which  describes  high-level 
control  logic  using  structured  English  is  used  as  needed  to 
describe  the  algorithms  in  this  specification.  A  description 
of  this  PDL  is  contained  in  Appendix  E.  Finally,  Appendix  F 
provides  a  complete  list  of  references. 

1.4  Role  of  Airspace  Probe  in  the  Overall  Air  Traffic  Control 
System  " 

The  Airspace  Probe  algorithm  evolves  from  the  functions  of  the 
current  Air  Traffic  Control  System  and  the  needs  of  the  future 
Air  Traffic  Control  System  as  given  in  the  FAA's  National  Air¬ 
space  System  Plan  [2,4]. 

1.4.1  System  Context 

The  Continental  United  States  airspace  is  partitioned  among  20 
centers  or  Air  Route  Traffic  Control  Centers  (ARTCCb).  The 
ARTCCs  control  regions  bounded  horizontally  by  polygons  that 
stretch  vertically  from  the  center  floor  to  60,000  feet.  Each 
center's  airspace  is  further  divided  into  areas ,  which  are  in 
turn  divided  into  sectors.  Areas  and  sectors  are  polygonal 
regions  with  floors  (either  a  specified  altitude  or  the  center 
floor),  and  ceilings.  The  sectors  of  each  area  are  staffed  by 
a  group  of  air  traffic  controllers  (or  controllers)  specific¬ 
ally  trained  for  that  area. 


In  the  current  ATC  system,  pilots  decide  their  desired  means  to 
reach  their  destination  consistent  with  current  navigational 
and  ATC  practices.  This  Intent  is  then  filed  with  the  ATC  sys¬ 
tem  as  a  flight  plan  and  approved  as  filed  or  altered  by  ATC 
for  operating  under  Instrument  Flight  Rules  (IFR).  Alterna¬ 
tively,  flight  plans  that  are  executed  dally  or  on  a  regularly 
scheduled  basis  reside  in  a  data  base  and  are  retrieved  auto¬ 
matically  unless  altered  or  suspended.  A  flight  plan  modifica¬ 
tion  may  be  initiated  by  a  controller  or  the  pilot.  Advanced 
automation  functions  of  the  AAS  can  deal  only  with  those  air¬ 
craft  filing  IFR  flight  plans. 

Controllers  are  responsible  for  monitoring  flights  as  they  pass 
through  their  sectors  and  for  helping  pilots  achieve  their 
objectives.  They  watch  a  block  of  symbols  representing  the 
aircraft's  radar  track  position  as  it  moves  across  a  display 
console;  the  aircraft's  identity,  altitude,  and  other  informa¬ 
tion  are  also  displayed.  Controllers  Institute  control  actions 
as  needed  to  perform  such  functions  as  helping  pilots  avoid 
close  approaches  with  other  aircraft,  honoring  pilot  requests 
for  new  routes,  rerouting  flights  to  avoid  special  airspaces 
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or  severe  weather,  and  queuing  aircraft  into  the  major  terminal 
areas. 

1. 4.1.2  Need  for  Airspace  Probe 


The  FAA  has  developed  an  automated  tool  for  the  controller,  En 
Route  Minimum  Safe  Altitude  Warning  (E-MSAW),  to  assist  in 
detection  of  penetration  of  restricted  flight  airspaces.  In 
that  function,  aircraft  track  positions  and  velocities  are  com¬ 
pared  to  the  coordinates  of  terrain  obstructions  to  determine 
if  penetrations  of  minimum  safe  altitude  could  cur.  The  con¬ 
troller  receives  a  displayed  warning  upon  algo  .ualc  detection 
of  an  imminent  penetration  of  minimum  safe  al  ude  standards. 
E-MSAW  provides  the  controller  with  an  alert  potentially 
dangerous  situations  where  aircraft  might  g<  too  close  to 
terrain  obstructions  (natural  or  man-made).  J  'g  as  pilots 
stay  on  published  routes,  controllers  need  short-term 
warnings  when  flights  stray  too  close  to  terrain  or  volumes 
wherein  general  flight  Is  restricted.  Pilots  filing  published 
routes  are  provided  with  both  minimum  altitude  requirements  and 
the  assurance  that  no  published  route  penetrates  a  restricted 
flight  regime.  A  flight  violating  published  altitude  require¬ 
ments  or  penetrating  a  restricted  area  implies  the  need  for 
"blunder"  detection  for  the  controller.  Such  a  detection 
device  is  not  a  strategic  prediction  of  problems. 

With  the  increase  in  the  use  of  unrestricted,  user-preferred 
routes  expected  as  the  advancing  level  of  automation  allows, 
pilots  will  run  the  risk  of  unintentionally  filing  too  close  to 
restricted  flight  airspaces.  Controllers  need  more  efficient 
long-term  warnings  for  penetrations  predicted  for  this  growing 
class  of  flyer 8. 

The  Airspace  Probe  is  an  extension  of  the  E-MSAW  concept.  Air¬ 
space  Probe  can  alert  the  controller  long  periods  in  advance  of 
any  projected  penetration  of  pertinent  airspace  volumes.  It 
uses  an  ATC-derlved  aircraft  trajectory  rather  than  track 
information.  Airspace  Probe  provides  for  an  alert  not  only  for 
E-MSAW  areas  but  for  other  areas  as  well.  These  could  Include 
NAS-adapted  Restricted  Areas  and  Warning  Areas,  Military  Opera¬ 
tions  Areas,  and  other  Special-Use  Airspaces.  The  alert  can 
then  lead  to  a  resolution  of  the  penetration  far  in  advance  of 
projected  entry  time,  thus  helping  to  avoid  inefficient 
maneuvers  while  facilitating  greater  use  of  user-preferred 
routes. 
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1.4.2  Role  of  Airspace  Probe  in  Future  System  Enhancements 


In  the  initial  version  of  the  Advanced  Automation  System  [1], 
the  Airspace  Probe  will  be  only  a  detection  service  which 
provides  results  for  a  manual  resolution  process.  Later, 
results  will  feed  into  an  automatic  resolution  service.  As 
Initially  conceived,  the  Airspace  Probe  detects  conflicts,  the 
display  generation  functions  are  responsible  for  gathering 
information  for  the  controller  and  displaying  that  information, 
and  the  controller  plans  resolution  maneuvers  for  the  air¬ 
craft.  In  a  scenario  of  the  evolution  of  ATC  automation  [5], 
future  plans  provide  for  continuing  the  current  strategic 
detection  service  and  decreasing  the  controller's  responsibil¬ 
ity  for  generating  resolution  maneuvers.  This  may  be  done  by 
allowing  the  controller  to  choose  from  a  ranked  list  of  alter¬ 
native  resolutions  or  by  providing  the  automatic  resolution 
service  itself. 

Future  automation  plans  also  provide  that  Airspace  Probe  and 
related  functions  will  predict  and  resolve  penetrations  with  an 
enhanced  set  of  geographic  areas  and  include  a  mechanism  for 
strategic  conflict  detection  and  resolution  for  dynamic  areas 
(such  as  weather),  as  well. 

1.5  Airspace  Probe  Summary 

The  Airspace  Probe  provides  an  aid  for  controllers  to  determine 
if  an  aircraft  flight  plan  penetrates  designated  areas  called 
"Minimum  Safe  Altitude  Warning  Areas”  and  "Special-Use  Air¬ 
spaces.”  Special-Use  Airspaces  are  defined  in  the  Airman's 

Information  Manual  [6].  These  Include,  but  are  not  limited  to, 
Restricted  Areas,  Warning  Areas,  Prohibited  Areas,  and  Military 
Operations  Areas.  Each  aircraft's  planned  route  of  flight  is 
compared  against  all  these  areas  to  check  for  Intersections  or 
penetrations.  If  a  penetration  is  found,  the  identity  of  the 
area  and  the  penetration  coordinates  are  saved  for  retrieval 

and  display  as  appropriate  by  the  display  functions. 

1.5.1  Operational  Description 

Airspace  Probe  operates  within  the  context  of  the  AAS  [1]. 

Other  functions  separate  from  Airspace  Probe  provide  Airspace 
Probe  with  the  environmental  data  needed  to  predict  penetra¬ 
tions  of  certain  airspaces.  These  d3ta  are  discussed  in 

adaptation  guidelines  {7],  Adaptation  is  that  process  of  col¬ 
lecting  important,  relatively  static  environmental  data  and 
storing  them  in  system-accessible  data  bases.  Included  in  such 


data  are  the  geographical  boundaries  of  the  volumes  of  airspace 
which  are  used  by  Airspace  Probe. 

From  a  controller's  point  of  view,  Airspace  Probe  (in  combina¬ 
tion  with  the  display  generating  functions,  Situation  Display, 
and  Trajectory  Estimation)  provides  information  to  help  detect 
penetrations  of  special  airspaces.  The  Airspace  Probe  function 
uses  data  describing  the  Special-Use  Airspaces  and  E-MSAW  areas 
and  maintains  the  data  describing  any  penetrations  predicted. 
When  a  penetration  is  detected  between  an  aircraft  trajectory 
and  a  Special-Use  Airspace  or  E-MSAW  area,  data  for  a  control¬ 
ler  display  is  updated.  This  operation  is  described  in  more 
detail  by  Swedish  et  al.  [3].  The  displays  may  provide  such 
details  of  the  penetrations  as: 

•  Aircraft  involved 

•  Location 

•  Conflict  type 

•  Time  to  conflict 

•  Graphical  display  of  conflict 

From  this  information,  the  controller  may  develop  a  tentative 
resolution  approach  such  as  amending  the  flight  plan.  This  may 
be  done  in  the  context  of  the  Trial  Plan  Probe  described  oper¬ 
ationally  by  Swedish  [3).  If  a  change  in  the  flight  plan  is 
involved,  the  controller  may  receive  probe  results  to  make  sure 
the  tentative  resolution  resolves  the  penetration  and  does  not 
create  new  ones.  If  the  penetration  is  not  resolved,  the  con¬ 
troller  may  try  another  tentative  resolution.  If  the  penetra¬ 
tion  is  resolved,  the  flight  plan  change  may  be  accepted  (by 
the  controller)  and  the  flight  plan  data  base  is  updated  (in 
functions  separate  from  Airspace  Probe).  The  controller  does 
not  Invoke  Airspace  Probe  by  itself  but  always  in  the  context 
of  a  flight  plan  amendment.  The  controller  has,  at  all  times, 
the  means  to  ask  for  the  display  of  penetrations  in  a  different 
form  (i.e.,  graphical  rather  than  textual). 

1.5.2  Processing  Overview 

Data  describing  special  airspaces  are  maintained  in  the  data 
base  by  their  x,y  geographical  coordinates.  Other  information 
about  the  area  is  also  maintained  such  as  the  airspace  Identi¬ 
fication,  the  minimum  and  maximum  altitude,  and  the  activation 
and  deactivation  times  (where  applicable).  Polygons  may  be 
convex  or  may  be  mixed  (with  some  concave  angles).  Area  coor¬ 
dinates  may  only  be  changed  in  adaptation,  but  the  area  may  be 
temporarily  activated  or  deactivated  by  supervisor  request. 


Aircraft  trajectories  for  1FR  aircraft  with  valid  flight  plana 
are  constructed  by  the  Trajectory  Estimation  function.  These 
trajectories  are  maintained  as  a  series  of  points  designating 
x,y  (horizontal  position),  z  (altitude)  and  t  (time)  at  each 
point.  Once  these  trajectories  are  available,  then  Airspace 
Probe  can  derive  airspace  penetration  information. 

Airspace  Probe  works  in  tandem  with  Trajectory  Estimation: 
whenever  the  trajectory  for  an  aircraft  changes,  Airspace  Probe 
is  automatically  invoked  to  maintain  the  airspace  penetrations 
data  base.  Airspace  Probe  compares  the  trajectory  against  all 
pertinent  airspaces  that  are  currently  active  using  a  series  of 
progessively  finer  filters.  The  First-Order  Coarse  Filter  and 
Second-Order  Coarse  process  all  polygons  to  accumulate  candi¬ 
date  intersecting  object  polygons.  The  Fine  Filter  process 
this  object  polygon  list  to  determine  the  intersection  coordin¬ 
ates  (if  any).  When  trajectories  intersect  an  area,  a  data 
structure  which  maintains  information  about  the  penetration  Is 
defined  and  stored  in  the  data  base.  Any  of  the  Information 
maintained  in  the  data  base  may  be  available  for  display  to  the 
controller. 


DEFINITIONS  AND  DESIGN  CONSIDERATIONS 


Airspace  Probe  Includes  E-MSAW  capabilities  along  with  new 
capabilities.  Inclusion  of  an  extended  set  of  airspace  areas 
widens  the  responsibilities  of  Airspace  Probe  over  that  of 
E-MSAW,  but  the  basic  purpose  remains  unchanged  and,  so,  the 
algorithms  of  Airspace  Probe  remain  deeply  rooted  in  the 
previous  E-MSAW  work. 

This  section  introduces  terminology  used  in  this  specifica¬ 
tion.  Also  provided  is  a  set  of  design  considerations  which 
place  Airspace  Probe  firmly  within  the  AAS  context. 

2.1  System  Design  Definitions 

Some  terms  introduced  in  Section  1  of  this  specification  are  of 
global  Interest  across  the  AAS  environment  and  include  (in 
order  of  presentation): 

1.  Subfunction 

2.  Component 

3 .  Element 

4 .  Center 

5 .  Areas 

6.  Sectors 

7.  Controllers 

8 .  Flight  Plan 

9.  Penetration 

10.  Adaptation 

Other  terms  of  interest  only  to  Airspace  Probe  are  introduced 
below. 

2.1.1  Airspace  Types 

Special-Use  Airspaces  are  areas  wherein  aircraft  operations  are 
limited.  This  section  lists  and  defines  the  set  of  Special-Use 
Airspaces  referenced  in  this  specification.  Airspace  types  are 
further  defined  in  the  Airman's  Information  Manual  [6]. 

•  Controlled  Firing  Areas 

Controlled  Firing  Areas  are  areas  which  contain  activ¬ 
ities  which  could  be  hazardous  to  nonparticipating 
aircraft.  A  unique  feature  of  these  areas  is  that 
activities  are  suspended  if  spotter  aircraft,  radar,  or 
ground  look-out  positions  indicate  that  a  nonpartici¬ 
pating  Aircraft  is  approaching. 


Military  Operations  Areas  (MQAs)  consist  of  airspace 
defined  by  vertical  and  lateral  limits  which  are 
established  to  separate  military  training  activities 
from  IPR  traffic. 


•  Prohibited  Areas 

Prohibited  Areas  are  airspace  volumes  within  which  the 
flight  of  aircraft  is  prohibited.  They  contain  air¬ 
space  of  defined  dimensions  identified  by  an  area  on 
the  surface  of  the  earth.  These  areas  are  established 
for  security  or  other  reasons  associated  with  the 
national  welfare. 


•  Restricted  Areas 

Restricted  Areas  are  airspace  volumes  within  which  the 
flight  of  aircraft  is  restricted.  Aircraft  activities 
within  these  areas  must  be  confined  because  of  the 
content  of  activities  occurring  in  the  area. 
Restricted  areas  denote  the  existence  of  unusual,  often 
invisible  hazards. 


•  Warning  Areas 


Warning  Areas  are  airspace  beyond  the  three-mile  limit 
over  international  waters  which  may  contain  hazards  and 
should  not  be  penetrated  during  periods  of  activity. 
Even  though  the  activities  in  warning  areas  may  be  as 
hazardous  as  those  in  restricted  areas,  areas  over 
international  waters  cannot  be  legally  designated  as 
restricted  areas. 


2.1.2  Modeling  Environment  Terms 


A  center  represents  a  volume  of  airspace  for  air  traffic  con¬ 
trol.  Enclosing  the  center  is  the  planning  region.  The 
boundary  of  the  planning  region  is  considered  to  be  some  hori¬ 
zontal  distance  outside  that  of  the  center:  some  20  to  30 
minutes  of  flying  time  in  all  directions. 


Trajectory  Estimation  [Vol.  1]  provides  Airspace  Probe  with  a 
trajectory  for  each  aircraft  with  an  IFR  flight  plan.  A 
trajectory  is  a  predicted  path  for  the  aircraft  through  the 
three  spatial  dimensions  (x,  y,  z)  and  time.  Each  trajectory 
is  conceptually  a  continuous,  smooth  curve  in  four  dimensions. 
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However,  trajectories  are  aodeled  as  a  series  of  lines  (In 
space-time)  called  segments,  joined  together  at  their  end¬ 
points,  called  cusps.  The  data  base  provides  trajectory  infor- 
aation  as  a  list  of  cusps: 

jq  -  (x,  y,  z,  t)±  |  1  -  1,  .  .  .,  nj. 

The  segaents  are  the  iaplled  straight  lines  joining  adjacent 
cusps.  The  trajectory  is  the  ordered  sequence  of  these  seg¬ 
aents. 

It  is  convenient  for  purposes  of  Airspace  Probe  to  enclose  the 
horizontal  extent  of  the  planning  region  in  a  grid.  The  grid 
covers  the  planning  region  with  squares,  called  cells,  aligned 
with  the  x,y  coordinate  axes  of  the  coordinate  system  used  by 
Trajectory  Estimation.  These  cells  provide  a  reference  for 
geographical  features  in  terms  of  their  location  within  a 
numbered  cell. 

The  grid  structure  associated  with  E-MSAW  is  the  underlying 
Radar  Sort  Box  grid  structure  which  is  used  primarily  in  Radar 
Data  Processing.  This  grid  structure  was  updated  to  incor¬ 
porate  E-MSAW  information  as  described  in  NAS  Stage  A  Automatic 
Tracking  specification  [8J.  The  requirements  of  Airspace  Probe 
are  satisfied  by  this  grid  structure.  However,  there  is  no 
guarantee  that  the  AAS  will  incorporate  the  Radar  Sort  Box 
concept.  Consequently,  the  remainder  of  this  document  refers 
to  an  Airspace  Probe  "grid"  to  give  emphasis  to  the  fact  that  a 
similar  type  of  grid  structure  is  necessary  for  Airspace  Probe 
algorithms. 

2.1.3  Airspace  Probe  Terms 

Airspace  Probe  works  with  a  trajectory  and  a  set  of  airspace 
volumes.  The  trajectory  is  said  to  belong  to  the  subject  air¬ 
craft.  The  airspace  volumes,  which  are  assumed  by  Airspace 
Probe  to  be  cross-referenced  to  the  grid  through  adaptation, 
form  the  set  of  object  polygons. 

The  Airspace  Probe  algorithm  is  executed  through  a  sequence  of 
filters.  A  filter  is  a  logical  subalgorithm  the  input  of  which 
is  a  subset  of  all  object  polygons  and  the  output  of  which  is  a 
subset  of  the  input.  Input  to  the  first  filter,  called  the 
First-Order  Coarse  Filter,  is  the  entire  object  polygon  set. 
Output  from  the  last  filter,  called  the  Fine  Filter,  is  the  set 
of  encounters.  An  encounter  is  an  object  polygon  penetrated  by 
the  subject's  trajectory.  A  nominee  is  an  object  polygon  which 
is  input  to  any  filter  except  the  First-Order  Coarse  Filter. 


The  subject's  trajectory,  upon  initial  processing  in  Airspace 
Probe,  aust  be  cross-referenced  to  the  grid.  In  this  process, 
the  list  of  cells  that  the  trajectory  penetrates,  called  the 
grid-chain,  is  computed.  The  logical  entity  responsible  for 
the  cross-referencing  is  called  the  grid-chain  generator. 

2.2  Design  Considerations 


Environmental  adaptation  is  assumed  to  record  the  identities, 
geoaetry  and  coordinates  of  all  E-MSAW  areas  and  Special-Use 
Airspaces  (SUAs)  that  are  physically  within  the  planning 
region.  The  E-MSAW  areas  and  SUAs  are  simple  polygons  in  an 
(x,y)  projection  with  flat  tops  and  bottoms.  The  E-MSAW  areas 
aay  cover  the  planning  region  giving  an  approximation  to  the 
geography  and  radar  receiving  capabilities  of  the  underlying 
asp.  They  all  touch  the  ground  and  are  under  25,500  feet  in 
altitude.  The  other  SUAs  aay  be  detached,  floating  above  the 
planning  region.  The  estimated  population  of  protected  air¬ 
spaces  is  about  500  where  most  of  them  are  E-MSAW  polygons. 

A  typical  planning  region  is  a  polygon  with  vertices  established 
as  latitude,  longitude  points.  In  environmental  adaptation, 
the  planning  region  is  apportioned  among  multiple  cells.  Next, 
all  E-MSAW  areas  and  SUAs  are  positioned  in  the  grid  as  shown 
in  Figure  2-1.  When  adaptation  is  completed,  each  cell  data 
element  contains  the  identity  of  all  polygons  which  Intersect 
that  cell.  The  opposite  is  also  true.  Each  polygon  data 
element  adapted  contains  the  list  of  grid  cells  the  polygon 
Intersects.  Maintenance  of  both  the  polygon- by-cell  and 
cell-by-polygon  data  bases  is  required  to  provide  access  to  the 
cells  when  the  polygons  are  activated  or  deactivated,  and  to 
provide  access  to  the  polygons  when  the  cells  enclosing  the 
flight  plan  segment  change. 

The  E-MSAW  function  which  exists  in  NAS  Stage  A  has  been  used 
as  a  source  of  some  of  the  algorithms  of  Airspace  Probe.  The 
E-MSAW  function  has  limited  warning  capabilities  in  comparison 
to  those  which  have  evolved  for  Airspace  Probe.  E-MSAW 
provides  a  tactical  warning  message  to  controllers  when  air¬ 
craft  are  too  close  to  terrain  obstructions.  E-MSAW  warns  of 
imminent  penetration  of  airspaces  where  "imminent"  is  defined 
to  be  less  than  five  minutes  into  the  future. 

At  the  other  end  of  the  tactical-strategic  spectrum,  Airspace 
Probe  provides  information  to  construct  a  warning  message  to 
controllers  when  planned  aircraft  trajectories  get  too  close  to 
terrain  and  other  Special-Use  Airspaces.  Using  aircraft 


FIGURE  2-1 

SPECIAL-USE  AIRSPACE  DEFINED  ON 
PLANNING  REGION  GRID 
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trajectories,  Airspace  Probe  performs  the  same  function  without 
the  temporal  limitations. 

The  algorithm  supporting  the  Airspace  Prjbe  has  evolved  from 
the  E-MSAW  algorithm  [8,9].  The  NAS  Adaptation  Process  [7] 
provides  the  environmental  data.  Adaptation  and  the  E-MSAW 
algorithm  can  be  summarized  as  shown  below: 

e  E-MSAW  Area  Adaptation: 

1.  The  airspace  of  the  planning  region  is  divided  Into 
a  regular  grid. 

2.  The  airspace  terrain  polygons  are  cross  referenced 
with  respect  to  the  grid. 

•  E-MSAW  Algorithm: 

1.  The  current  position  and  velocity  of  the  aircraft 
are  projected  ahead  for  some  fixed  time  period 
(nominally  two  minutes)  based  on  radar  track  data. 

2.  The  intersections  between  projected  line  segments 
and  polygons  are  determined. 

3.  The  intersections  are  reported  to  the  controller. 

The  two  new  features  of  Airspace  Probe  are  incorporation  of 
additional  airspace  volumes  and  the  use  of  the  aircraft  trajec¬ 
tory  for  early  penetration  prediction.  In  addition,  penetra¬ 
tions  are  maintained  in  the  data  base  for  display  to  the 
controller  (either  immediate  or  later  display).  The  Airspace 
Probe  algorithm  works  as  shown  below: 

e  E-MSAW  Area  and  Special-Use  Airspace  Adaptation; 

1.  The  airspace  of  the  planning  region  is  divided  into 
a  regular  grid. 

2.  The  E-MSAW  areas  and  Special-Use  Airspaces  are 
cross-referenced  with  respect  to  the  grid. 

e  Airspace  Probe  Algorithm: 

1.  The  planned  aircraft  trajectory  is  examined. 
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I.  AIRSPACE  PROSE  FUNCTIONAL  DESIGN 

This  section  Identifies  the  environment  in  which  Airspace  Probe 
is  to  work  in  the  AAS.  The  input  and  output  data  are  identi¬ 
fied  along  with  activation  sequences.  At  the  end  of  this 
section,  the  major  subfunctions  of  Airspace  Probe  are  identi¬ 
fied  and  a  description  of  each  subfunction  is  provided. 

3.1  Environment 


The  prediction  process  of  Airspace  Probe  uses  the  stored 
polygon  information  along  with  the  predictions  of  future  posi¬ 
tions  for  aircraft  from  Trajectory  Estimation  to  search  for 
positions  where  an  aircraft  path  (in  four  dimensions)  pene¬ 
trates  an  E-MSAW  or  Special-Use  Airspace  volume.  Figure  3-1 
depicts  the  Airspace  Probe  functional  environment. 

3.1.1  Input  Data  and  Activation 

The  Airspace  Probe  function  requires  an  initialized  data  base 
containing  various  types  of  data  defining  the  environment.  The 
environment  ih  divided  into  a  regular  grid  covering  the  entire 
x,y  extent  of  the  planning  region.  The  (x,y,z,t)  coordinates 
of  E-MSAW  and  Special-Use  Airspaces  are  input  and  cross- 
referenced  to  the  grid. 

Airspace  Probe  uses  this  environmental  definition  and  data 
which  specifies  the  trajectory  to  be  probed.  The  algorithm 
typically  processes  one  aircraft  trajectory.  In  either  case, 
the  algorithm  operates  the  sane  way.  An  aircraft  is  selected 
(separate  from  the  Airspace  Probe  algorithm)  and  the  trajectory 
is  compared  against  the  object  polygons.  A  list  of  those  poly¬ 
gons  which  Intersect  the  aircraft  trajectory  is  formed  and  data 
is  stored  describing  the  intersection. 

3.1. 1.1  Input  Data 

Airspace  Probe  requires  input  data  through  adaptation.  Polygon 
adaptation  ensures  that  the  following  data  are  accumulated 
which  describe  the  E-MSAW  and  Special-Use  Airspace  environment: 

•  Grid  specification 

•  Airspace  polygon  coordinates,  (x,y,z,t),  for  each 
E-MSAW  Area  and  Special-Use  Airspace 

•  Polygons  further  defined  In  a  polygon  data  base  cross- 
referenced  with  the  grid 
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Airspace  Probe 


Airspace  Probe  must  further  be  provided  with  an  aircraft's 
trajectory  which  describes  the  path  the  aircraft  Is  predicted 
to  take  through  the  planning  region. 

3.1. 1.2  Automatic  Activation  Sequences 

Airspace  Probe  aay  be  initiated  automatically  to  determine 
penetrations  of  protected  airspace  whenever  the  following 
events  occur: 

•  The  trajectory  estimate  for  an  aircraft  changes.  This 
could  occur  when  a  new  aircraft  enters  the  system, 
updates  to  trajectory  time  values  are  made,  or  a 
candidate  plan  is  being  examined  by  the  controller. 
(See  Section  3. 1.1. 3) 

e  The  time  bounds  on  any  one  Special-Use  Airspace  change 
through  supervisory  action.  (See  Section  3. 1.1. 4) 

3.1. 1.3  Controller  Initiating  Sequences 

A  controller  may  implicitly  initiate  Airspace  Probe  when  he  has 
used  his  strategic  planning  mechanism  (l.e..  Trial  Plan  Probe 
as  described  by  Swedish  [2])  to  include  some  alteration  in  the 
aircraft's  plan  such  as  a  change  to  the  assigned  altitude  or 
speed.  In  these  cases,  Airspace  Probe  is  Invoked  automatic¬ 
ally.  If  the  trajectory  is  not  changed,  however,  the  control¬ 
ler  should  not  request  Airspace  Probe  since  no  new  information 
can  be  generated.  He  aay  only  request  more  information  about 
the  penetrations  already  detected  and  stored. 

3.1. 1.4  Supervisor  Activation  and  Deactivation 

The  supervisor  nay  implicitly  initiate  the  Airspace  Probe  when 
he  activates  or  deactivates  an  area.  In  this  case,  the  super¬ 
visor  would  change  the  time  limits  on  a  certain  Special-Use 
Airspace.  This  action  externally  activates  an  Airspace  Probe 
on  a  (possibly  large)  population  of  aircraft.  The  activation 
of  Airspace  Probe  for  each  aircraft  Involved  in  this  population 
is  automatic.  This  activation  sequence  is  not  described  fur¬ 
ther  in  this  specification. 


3.1.2  Output 

The  penetration  detection  algorithms  of  Airspace  Probe  identify 
encounters  and  store  the  data  for  use  by  the  controller. 
Several  types  of  data  are  stored  (cf:  Vol.  5,  "Environmental^ 
Conflict"). 


•  Polygon  identification 

•  Aircraft  Identification 

•  Encounter  tiae 

•  Encounter  coordinates 

•  Advisory  time 

3. 1.2.1  Information  to  the  Controller 

The  Airspace  Probe  stores  penetration  information  and  makes  it 
available  for  display  by  the  display  function.  Any  time  a 
penetration  between  an  aircraft  trajectory  and  E-MSAW  areas  or 
Special-Use  Airspaces  is  predicted,  data  for  a  controller  dis¬ 
play  is  updated.  This  data  provides  information  about  the 
penetrations  of  all  aircraft  into  E-MSAW  and  Special-Use 
Airspace  polygons  such  as: 

e  Aircraft  identification 
e  Sector,  grid,  and  polygon  identification 
e  Penetration  coordinates 
e  Time  to  penetrations 

The  display  function  is  maintained  as  a  separate  entity.  Thus, 
it  has  logic  of  its  own  to  determine  encounters  eligible  for 
display  to  the  appropriate  controller,  select  appropriate  data 
to  display,  provide  the  desired  display  format,  and  choose  the 
logical  display  on  the  appropriate  logical  device. 

The  display  function  sorts  Airspace  Probe  encounter  data  by 
time  and  generates  two  types  of  warnings.  If  the  time  to  pene¬ 
tration  is  more  than  X  (system  parameter)  minutes,  an  advisory 
message  is  sent  to  the  controller  who  is  currently  responsible 
for  the  aircraft.  If  the  time  to  penetration  is  less  than  X 
(system  parameter)  minutes,  an  alert  message  is  sent  to  the 
controller  responsible  at  the  position  of  penetration. 

The  display  function  selects  appropriate  data  for  display  to 
the  controller  and  provides  the  display  format  such  as  arrange¬ 
ment,  choice  of  graphic  or  alphanumeric  information,  and 
(possibly)  color  of  data  items.  In  both  the  advisory  and  alert 
messages,  the  controller  is  presented  with  information  required 
to  identify  the  penetration  and  formulate  a  resolution.  All 
information  necessary  to  support  the  display  function  exists  in 
the  penetrations  data  base  maintained  by  Airspace  Probe. 


3. 1.2. 2  Information  to  the  Supervisor 

When  areas  are  activated  or  deactivated  by  the  supervisor,  no 
special  information  is  provided  from  the  Initiation  of  Airspace 
Probe.  However,  the  display  functions  should  Inform  the  super¬ 
visor  that  his  request  has  been  honored. 

3.2  Design  Assumptions 

This  section  describes  some  assumptions  made  in  the  design  of 
Airspace  Probe  algorithms.  Of  special  Importance  are  those 
assumptions  placed  on  the  context  of  the  environmental  data. 

3.2.1  Polygon  Adaptation 

Adaptation  of  E-MSAW  areas  and  Special-Use  Airspace  is  assumed 
in  this  specification  to  provide  the  environmental  information 
used  by  Airspace  Probe  algorithms.  Ab  in  E-MSAW,  the  polygons 
are  assumed  to  be  cross-referenced  to  a  grid  where  each  polygon 
data  element  contains  the  Identity  of  all  the  cells  it  inter¬ 
sects,  and  each  cell  data  element  contains  the  identity  of  all 

the  polygons  that  intersect  it.  In  particular,  the  following 
data  are  assumed: 

#  Cell  data  element  (cf:  Vol.  5,  "Environmental_Cell” ) 

-  cell  identification 

-  the  polygon  Identification  for  each  polygon 

intersecting  this  cell 

e  Polygon  data  element  (cf:  Vol.  5,  Special_Use_Airspaces 
and  E_MSAW_Areas) 

-  polygon  identification 

-  cell  identification  for  each  cell  this  polygon 

Intersects 


airspace  type  (E-MSAW,  etc.) 
polygon  type  (convex,  mixed) 
list  of  (x,y)  vertices  for  the  polygon 


altitude  extent  of  the  polygon 


time  extent  of  the  polygon 

The  vertices  of  the  polygon  are  assumed  to  be  stored  in  a 
consistent  ordering  scheme:  "clockwise"  is  used  in  this 

specification  since  that  convention  was  adopted  by  E-MSAW. 
Furthermore,  this  specification  assumes  that  the  vertices 
stored  for  a  polygon  extends  the  real  boundary  of  the  polygon 
by  a  system  parameter  number  of  miles.  This  is  necessary  to 
account  for  the  lateral  positional  uncertainty  In  a  trajec¬ 
tory.  This  notion  Is  portrayed  in  Figure  3-2. 

3.2.2  Inherited  E-MSAW  Assumptions 

Several  major  design  assumptions  are  derived  from  the  design  of 
E-MSAW  [8,9]: 

s  Special-Use  Airspaces  can  be  processed  algorithmically 
like  E-MSAW  polygons  are  processed. 

s  It  is  not  necessary  to  restrict  Special-Use  Airspace 
Polygons  to  convex  polygons. 

s  When  trajectories  intersect  a  polygon  several  times, 
certain  multiple  intersections  can  be  treated  as  one 
unique  penetration. 

3.3  Subfunctions 


Three  subfunctions  to  Airspace  Probe  are  identified  and 
described  in  this  section.  Each  subfunction  refines  an  input 
list  of  object  polygons.  At  the  termination  of  the  Airspace 
Probe  process,  an  output  set  of  encounters  is  produced. 

3.3.1  First-Order  Coarse  Filter 


The  First-Order  Coarse  Filter  defines  a  nominee  in  terms  of  the 
x,y  closeness  of  a  polygon  to  a  trajectory.  The  trajectory 
representing  the  aircraft's  path  is  logically  superimposed  on 
the  planning  region  grid  and  the  grid-chain  extracted.  Poly¬ 
gons  named  in  each  cell  of  the  confining  grid-chain  are  added 
to  the  list  of  first  level  nominee  polygons.  Each  such  nominee 
has  the  property  that  the  aircraft's  trajectory  intersects  a 
grid  cell  the  polygon  also  intersects.  They  are,  therefore, 
"close"  (relative  to  the  grid).  This  process  is  shown  in 
Figure  3-3. 


Input  Polygon 
Expanded  Polygon 


FIGURE  3-2 

EXPANDED  POLYGON  BOUNDARY 
FOR  AIRSPACE  PROBE 


FIGURE  3-3 

FIRST-ORDER  COARSE  FILTER  SELECTION 


The  Second-Order  Coarse  Filter  defines  a  nominee  in  terms  of  an 
x,y,z,t  closeness  measure  of  a  polygon  to  the  trajectory.  The 
polygons  identified  in  the  First-Order  Coarse  Filter  are  again 
compared  to  the  trajectory.  A  series  of  interval  intersection 
tests  are  performed  between  trajectory  segments  and  one-  and 
two-dimensional  circumscribed  right  rectangles  that  envelop  the 
polygon. 

3.3.3  Fine  Filter 

The  Fine  Filter  defines  an  encounter  in  terms  of  an  exact 
intersection  between  the  polygon  and  a  trajectory  segment.  The 
polygons  Identified  by  the  Second-Order  Coarse  Filter  are  again 
compared  to  the  trajectory  segment.  Those  polygons  with  the 
property  that  they  intersect  the  aircraft  trajectory  are 
identified. 

3.3.4  Encounter  Processing 

Encounter  Processing  stores  information  about  the  encounters 
identified  by  the  Fine  Filter.  This  data  includes  information 
such  as  the  aircraft  ID,  route,  altitude,  time  and  position  of 
penetration,  and  the  identification  of  the  Special-Use  Airspace 
or  E-MSAW  area. 

3.4  Extendability 

Airspace  Probe  is  expected  to  be  enhanced  in  the  future  to 
predict  penetrations  of  aircraft  trajectories  against  weather 
polygons.  This  might  be  accomplished  by  generating  a  series  of 
static  polygons  representing  the  weather  cell  at  various  times 
t-minute8  apart,  each  with  a  lifetime  of  t-minutes  or  more. 
Such  an  extension  requires  no  changes  in  the  current  algo¬ 
rithm.  An  alternative  approach  might  define  polygons  to  be 
dynamic  in  nature  with  an  Implied  velocity  vector  and  time 
extent.  This  dynamic  nature  would  force  changes  in  the  Air¬ 
space  Probe  algorithm  in  two  areas. 

First,  the  moving  polygon  concept  does  not  fit  well  with  the 
grid  structure  serving  the  First-Order  Coarse  Filter.  There  is 
no  temporal  limit  in  the  grid  structure,  itself,  and  a  moving 
area  would  then  cut  a  "swath"  into  the  grid.  For  this  reason, 
each  moving  polygon  should  not  be  incorporated  into  the  Grid, 
but  each  moving  polygon  should  automatically  become  a  First- 
Order  Nominee  for  every  aircraft. 


Second,  the  Incorporation  of  moving  polygons  into  the  polygon 
population  forces  several  upgrades  in  the  execution  of  the 
Second-Order  Coarse  Filter  and  in  the  Fine  Filter.  The  logic 
of  these  two  entitles  can  be  easily  changed  to  consider  every 
polygon  a  dynamic  polygon  (with  E-MSAW  and  Special-Use  Air¬ 
spaces  having  an  assumed  zero-velocity  vector).  A  switch  to  a 
relative  geometry  (or  aircraft  centered)  coordinate  system  can 
be  made  at  the  outset  of  processing,  and  the  remainder  of  the 
filters  executed  as  specified. 


DETAILED  DESCRIPTION 


The  penetrat  on  detection  algorithms  of  Airspace  Probe  are 
arranged  in  a  series  of  progressively  more  discriminating 
filters.  Ai  space  Probe  is  composed  of  a  First-Order  Coarse 
Filter,  a  Second-Order  Coarse  Filter,  a  Fine  Filter  and  an 
Encounter  Processing  routine.  Polygons  passing  through  all  the 
filters  are  placed  on  a  list  of  polygons  which  intersect  the 
aircraft  trajectory.  Figure  4-1  illustrates  the  relationship 
of  the  components  in  the  Airspace  Probe. 

4.1  First-Order  Coarse  Filter 


4.1.1  Mission 


The  First-Order  Coarse  Filter  for  Airspace  Probe  is  a  mechanism 
for  quickly  selecting  the  proper  subset  of  polygons  (i.e., 
those  which  may  Intersect  the  aircraft  trajectory)  for  further 
Airspace  Probe  processing.  The  inclusion  of  Minimum  Safe 

Altitude  Warning  Areas  into  the  population  of  polygons  con¬ 

sidered  by  Airspace  Probe  makes  Buch  a  filter  mandatory  for 
reasons  of  efficiency.  There  can  be,  in  the  adaptation  data 
base,  several  hundred  Minimum  Safe  Altitude  Warning  Areas  which 
can  describe  the  topography  of  the  underlying  planning  region. 
In  fact,  the  whole  planning  region  could  be  covered  by  such 
polygons. 

The  First-Or  ler  Coarse  Filter  of  Airspace  Probe  is  especially 
constructed  to  use  stored  (adapted)  geographical  information 
about  the  location  of  polygons  and  information  from  the 
trajectory  of  the  aircraft  to  eliminate  polygons  on  the  basis 
of  some  a  priori  measure  of  closeness.  Conceptually,  if  the 

patn  of  the  aircraft  is  contained  entirely  in  the  southern 

section  of  a  planning  region  while  a  polygon  is  in  the  north, 
the  polygon  should  be  eliminated  from  further  processing. 

The  selected  polygons  which  are  close  to  the  aircraft  path 
resulting  from  such  a  coarse  filter  should  be  a  small  subset  of 
the  total  polygon  population.  That  subset  comprises  a  set  of 
nominees.  Iven  though  the  aircraft's  path  is  close  to  the 
polygon,  the  path  of  the  aircraft  may  or  may  not  intersect  the 
extent  of  a  nominee  polygon.  Further  Airspace  Probe  processing 
is  necessary  to  determine  the  actual  penetration  status  of  the 
aircraft  path  with  respect  to  each  nominee. 


ROUTINE  Airapace_Probe; 

PARAMETERS 

Loc_Fl_Id  IN; 

DEFINE  VARIABLES 

Loc_Fl_Id  .The  Identification  of  the  aircraft  being 

probed  for  airspace  conflicts  ;  . 

## 

CALL  FI ra t_Ord e r_^Coar se_Fllt *r  (Loc_Fl_I d  INJ; 

CALL  Second_Order_Goar*e_Flltar; 

CALL  Plne_Filter; 

CALL  Encounter_Proce88lng(Loc_Fl_Id  IN); 

END  Alrspace_Probe; 


FIGURE  4-1 
AIRSPACE  PROBE 


The  First-Order  Coarse  Filter  of  Airspace  Probe  is  designed  to 
provide  an  efficient  mechanism  for  examining  an  aircraft 
trajectory  with  respect  to  the  airspace  polygon  environment. 
It  uses  an  adapted  grid  structure  to  select  a  set  of  nominee 
polygons  from  the  polygon  population.  These  may  intersect  the 
trajectory  of  the  aircraft.  The  complement  of  the  set  of 
nominees  is  a  set  of  polygons  which  clearly  do  not  intersect 
the  trajectory.  To  perform  its  function,  the  First-Order 
Coarse  Filter  requires  input  defining  the  aircraft  trajectory 
and  input  defining  the  environmental  polygons  cross-referenced 
to  a  grid  structure.  It  produces  output  defining  a  list  of 
Nominees. 

The  sequence  of  elements  associated  with  the  First-Order  Coarse 
Filter  is  shown  in  Figure  4-2.  Program  design  language  is 
provided  in  this  section  for  each  element  shown  in  Figure  4-2 
with  the  exception  of  Grid  and  Linear_Discriminant_ClasBlfier. 
A  description  of  those  two  elements  is  provided  in  Appendix  B. 

Input  Data 

The  input  data  required  by  the  First-Order  Coarse  Filter 
consists  of: 

•  System  Global  Data  Base 
-  TRAJECTORIES 

The  aircraft's  trajectory  Is  obtained  from  the 
trajectories  table  using  the  flight  identification 
input  to  the  Airspace  Probe  algorithm. 


-  VOLUMES 

The  ceiling  altitude  of  each  airspace  volume  identi¬ 
fied  by  the  grid-chain  generator  is  obtained  for 
checking  purposes. 

-  ENV IRONMENTAL_CELL_CONTENTS 

A  cell  identified  by  the  grid-chain  generator  is 
cross-referenced  to  each  airspace  polygon  inter¬ 
secting  the  cell.  The  identities  of  each  polygon 
are  retrieved  for  possible  addition  to  the  list  of 
noninees . 


Fir8t_0rder_Coarae_Filter 
Cuspa_To_Segments 
Grld_Chaln_GeneratioQ 
Se  t_Up_Segment_Scan 
Grid 

S  can_Segment_To_Pi ck_Up_Cella 
Grid 
Add_Box 

Ge  t_Lowe  r_Le  f  t_Corne  r_Po  in  t  a 
Grid 

Linear  Discriminant  Claaalfler 


FIGURE  4-2 

ELEMENTS  OF  THE  FIRST-ORDER  COARSE  FILTER 


ENVIRONMENTAL  GRID  PARAMETERS 


The  nominal  cell  width  iB  obtained. 
ENVIRONMENTALjCELLS 

The  extent  of  a  cell  is  retrieved.  In  particular, 
the  x  and  y  extents  are  obtained  to  construct  the 
boundary  of  the  cell. 


Output  Data 

The  First-Order  Coarse  Filter  produces  a  list  of  nominee  poly¬ 
gons  which  must  be  processed  through  the  remainder  of  the 
Airspace  Probe  algorithm. 

•  Shared  Local  Data  Base 

-  FIRST_ORDERJJOMINEES 

The  identifies  of  the  First-Order  Coarse  Filter 
Nominee  polygons  are  stored  in  this  table.  These 
polygons  must  have  the  property  that  they  intersect 
a  cell  that  the  aircraft’s  trajectory  intersect  and 
the  ceiling  altitude  of  the  polygons  are  above  the 
minimum  altitude  of  the  trajectory. 

-  FL_CUSPS 

The  trajectory  of  the  aircraft  is  brought  into  local 
storage. 

-  SEGMENTS 

The  trajectory,  which  is  a  list  of  cusps,  is 
arranged  to  yield  an  explicit  line  segment  by  line 
segment  representation. 

4.1.3  Component  Design  Logic 

The  Airspace  Probe  First-Order  Coarse  Filter  is  responsible  for 
constructing  a  list  of  polygons  known  to  be  "close"  to  the 
route  of  the  aircraft.  The  route  of  the  aircraft  is  provided 
by  the  XYZT-Segments.  Figure  4-3  provides  a  description  of  the 
control  logic  for  the  First-Order  Coarse  Filter.  In  the 
element  Cusps_To_Segments  (Figure  4-4),  the  trajectory  of  the 
aircraft  is  obtained  and  processed  to  yield  the  ordered  set  of 
segments  which  represents  the  aircraft's  route. 


4-5 


ROUTINE  First  Order  Coarse_FIlter; 

PARAMETERS 

Loc_Fl_Id  DJ;  The  Flight  Identification 

REFER  TO  GLOBAL 
TRAJECTORIES  LN, 

VOLUMES  IN; 

REFER  TO  SHARED  LOCAL 

FIRST_ORDER_NOMINEES  OUT, 

FL_CUSPS  OUT; 

DEFINE  TABLES 

GRID_CHAIN_VOLUMES  The  volumes  found  in  the  grid  chain 

describing  the  aircraft  trajectory 
volume_id  The  volume  identifier 

first  cusp_time  The  first  cusp  before  the  grid  chain 

cell  containing  the  volume 
all  AGGREGATE  (volume_id,first_cusp_time); 

DEFINE  VARIABLES 

Loc_Fl_Id  The  Flight  Identification 

Min_Fl_Z  The  minimum  altitude  over  the  flight 

Ceiling_Altitude  The  celling  altitude  of  the  polgon 

being  examined; 

## 

FL_CUSPS  -  SELECT  FIELDS  tlme,x,y,z 
FROM  TRAJECTORIES 

WHERE  TRAJECTORIES. flJLd  E£  LOC_Fl_Id 
ORDER  BY  TRAJECTORIES. time; 

CALL  Cu8ps_To_Segment8 ; 

CALL  Grid_Chain_Generation  (GRID  CHAIN_VOLUMES  OUT); 

SELECT  FIELDS  z 
FROM  FLjCUSPS 
INTO  Min_Fl__Z 

WHERE  FL_CUSPS.z  E£  MIN(FL  CUSPS.z); 

REPEAT  FOR  EACH  GRID_CHAIN_VOLUMES  RECORD; 

SELECT  FIELDS  ceiling_altitude 
FROM  VOLUMES 
INTO  Ceiling  Altitude 

WHERE  GR I D_C HAI N_V OLUMES.volume_id  VOLUMES. volume_id 

IF  Min_Fl  Z  LT  Ceiling_Altitude 
THEN 

INSERT  INTO  F IRST_ORDER_N OMI NEES 
(all  *  GRID_CHAIN_V OLUMES .all); 

END  First  Order  Coarse  Filter; 


FIGURE  4-3 

FIRST  ORDER  COARSE  FILTER 


4 


4 


iil 


ROUTINE  Cusps  To  Segments; 
REFER' TO  SHARED  LOCAL 
FL_CUSPS  IN, 

SEGMENTS  OUT; 

DEFINE  VARIABLES 

FirstjCusp  Thi 


Previous  Time 


The  flag  indicating  that  the  first  cusp  of 
the  trajectory  is  being  processed 
The  time  of  the  previous  cusp; 


FirstjCusp  ■  "true"; 

REPEAT  FOR  EACH  FLjCUSPS  RECORD; 

IF  First_Cusp  Eg  "true" 

THEN 

INSERT  INTO  SEGMENTS 

(begin  ■  FL_CUSPS. cusp); 

Previou8_Time  ■  FLjCUSPS. time; 

Fir8t_Cusp  “  "false"; 

ELSE 

UPDATE  IN  SEGMENTS 

(end  *  FLjCUSPS. cusp) 

WHERE  SEGMENTS .beg ln_t  Eg  PreviousJTime ; 
IF  FL_CUSPS. time  NE  MAX  (FL_CUSPS.time) 
THEN 

INSERT  INTO  SEGMENTS 

(begin  -  FL_CUSPS. cusp); 

PreviousJTime  *  FLjCUSPS. time; 

END  Cu8p8_To_Segments; 

FIGURE  4-4 
CUSPS  TO  SEGMENTS  • 


The  Grid_Chain_Generation  (Figure  4-5)  represents  Airspace 
Probe's  capability  to  cross-reference  the  aircraft's  trajectory 
to  the  grid  structure.  The  output  of  this  routine  is  the  list 
of  all  the  volumes  associated  with  the  cells  that  the 
aircraft's  trajectory  intersects  (in  the  horizontal  plane). 

In  the  element  Set_Up_Segment_Scan  (Figure  4-6),  the  slope  for 
a  trajectory  segment  "is  computed  to  determine  the  coordinate 
with  the  fastest  change  per  unit  distance.  This  is  done  so 
that  the  algorithm  may  Increment  the  faster-changing  variable 
(called  the  "independent  variable")  to  step  to  the  next  row  (or 
column)  of  grid  cells  assuming  that  the  other  coordinate  will 
change  at  most  one  cell  in  either  a  positive  or  negative 
direction  (see  Figure  4-7).  The  element  also  identifies  the 
cells  containing  the  first  and  last  points  on  the  segment. 

At  each  grid  cell,  the  Independent  variable  is  Incremented  one 
step  in  grid-cell  coordinates  and  the  dependent  variable  is 
recalculated  by  the  element  Scan  SegmentJTo  Pick  UpjCells 
(Figure  4-8).  The  next  grid  cell  is  determined  from  these  new 
grid  cell  values.  If  it  is  found  that  the  dependent  variable 
has  changed  indicating  a  new  row  (or  column)  for  the  next  grid 
cell,  the  element  Add  Box  (Figure  4-9)  is  invoked  to  find  the 
intermediate  cell  which  has  been  crossed  (see  Figure  4-10). 

The  element  Add_Box  determines  which  Intermediate  cell  the 
trajectory  passes  through  as  follows  (see  Figure  4-11): 

1.  First,  it  is  determined  in  what  relation  the  current 
cell  stands  to  the  previous  cell  (upper  right,  etc.) 

2.  Second,  the  point  between  the  two  cells  is  found. 

3.  Next,  the  current  trajectory  segment  is  compared  to 

the  point  between  the  cells.  This  enables  the 

algorithm  to  determine  if  the  trajectory  segment 
passes  to  the  right  or  left  of  the  point.  This 
uniquely  determines  the  cell  that  the  trajectory  must 
pass  through  in  order  to  reach  the  current  cell. 

4.  Lastly,  this  intermediate  cell  is  added  to  the  grid 
chain  and  falls  in  the  proper  order. 

The  service  utilities  Get__Lower_Lef t_Corner_Points  (Figure 
4-12)  and  Put_Box_In_Grid_Chain  (Figure  4-13)  perform  data 
retrieval  and  depositing  to  support  Add_Box.  The  former 


ROUTINE  Grid  Chain  Generation; 

PARAMETERS 

GRID_CHAINVOL‘JMES  OUT; 

REFER  TO  GLOBAL 

ENVIRONMENTAL_CELL_CONTENTS  IN; 

REFER  TO  SHARED  LOCAL 
SEGMENTS  IN; 

DEFINE  TABLES 

GRID_CHAIN_CEI LS  The  cells  the  trajectory 


cell_id  The  cell  identifier 

f irst_cu8p_time  The  time  of  the  first 


cell 


intersects 
cusp  before  the 


GRID_CHAIN_V  OLUMES 

volume__id 
f ir st_cu8p_t ime 

TEMP 

volume_id 
DEFINE  VARIABLES 


The  volumes  within  the  cells  which 
intersect  the  trajectory 
Hie  volume  Identifier 
The  time  of  the  first  cusp  before  the 
cell 

A  temporary  table 

The  volume  identifier; 


Prev_Box 

Box 

Last  Box 


Slope 
StepX 
Step_Y 
Indep  Var 
##  “ 


The  last  cell  looked  at 
The  current  cell 

The  final  cell  of  the  trajectory  segment 
The  Y  vs  X  slope  of  the  segment 
The  Independent  variable  increment 
The  independent  variable  increment 
The  independent  variable; 


REPEAT  FOR  EACH  SEGMENTS  RECORD: 

CALL  Set_Up_Segment_Scan  (SEGMENTS. pair  IN,  Box  OUT, 
Last_Box  OUT,  Slope  OUT,  Step_X  OUT,  Step_Y  OUT, 
Indep_Var  OUT,  GRID_CHAIN_CELLS  OUT); 

CALL  Scan_Segment_To_Pick_Up_Cells  ( SEGMENTS . pair  IN, 
Box  IN,  Last_Box  IN,  Slope  IN,  Step_X  IN,  Step_Y  IN, 
Indep_Var  IN,  GRID_CHAIN  CELLS  INPUT); 

REPEAT  FOR  EACH  GRID_CHAIN_C ELLS  RECORD; 

TEMP  -  SELECT  FIELDS  volume  id 

FROM  ENVIRONMENTAL j:ELL_CONTENTS 
WHERE  ENV IR ONME NTAL_C E LL  CONTENTS. cell_id  EQ 
GRID_CHAIN_CELLS .  cell~*id ; 

REPEAT  FOR  EACH  TEMP  RECORD? 

INSERT  INTO  GRID_CHAIN_VOLUMES 

(volume_id  ■  TEMP.volume_id,  first_cusp_time  ■ 
GRID_CHAIN_CELLS . f irs  t_cu  sp_time ) ; 

END  Grid  Chain_Generation; 


FIGURE  4-5 

GRID  CHAIN  GENERATION 


ROUTINE  Set_Up_Segment_Scan; 

PARAMETERS 
SEGMENT  IN, 

Box  OUT, 

Las t_Box  OUT, 

Slope  OUT, 

Step_X  OUT, 

Step_Y  OUT, 

Indep_Var  OUT 

GRID  CHAIN  CELLS  OUT; 

REFER  TO  GLOBAL 


Environmental  Cell  Width  IN; 


DEFINE  TABLES 
SEGMENT 
begin_x 
begin_y 
begin_z 
begin_t 
end_x 
end_y 
end_z 
end_t 

GRID  CHAIN  CELLS 


The  current  trajectory  segment 
The  first  cusp  of  the  segment 


The  second  cusp  of  the  segment 


The  cells  intersecting  the  trajectory 


cell_id  The  cell  identifier 

f irst_cusp_time  The  time  of  the  first  cusp  before  the 

cell; 


DEFINE  VARIABLES 
Box 

Las  t_Box 
Slope 

Step_X 
Step_Y 
Indep_Var 
Delta_X 
Delta  Y 


The  first  cell  intersected 
The  last  cell  intersected 
The  slope  of  the  segment  with  respect  to 
the  independent  variable 
The  Independent  variable  increment 
The  independent  variable  increment 
The  independent  variable 
The  segment  X  extent 
The  segment  Y  extent; 


FIGURE  4-6 
SET  UP  SEGMENT  SCAN 
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CALL  Grid  ( SEGMENT. beginx  IN,  SEGMENT. begins  IN, 

Box  OUT); 

INSERT  INTO  GRID_CHAIN_CELLS 

(cell_id  ■  Box,  f irat_cusp_time  ■  SEGMENT. begin_t) 
De lta_X  ■  SEGMENT. end_x  -  SEGMENT,  beginjc; 

Delta_Y  -  SEGMENT. end_y  -  SEGMENT. begin_y; 

Step_X  ■  SIGN  (Delta_X)  *  Environmental_Cell_Width; 
Step_Y  ■  SIGN  (Delta_Y)  *  Envirotunental_Cell_Width; 
Slope  *  Delta_Y/Delta_X; 

IF  ABS( Slope)  LT  1 
THEN 

IndepVar  -  "X"; 

ELSE 

Indep_Var  “  "Y”; 

Slope  ■  Delta_X/Delta_Y; 

CALL  Grid  ( SEQ1ENT . end_x  IN,  SEGMENT . end_y  IN, 

Las t_Box  OUT); 

END  Set_Up_Segment_Scan; 


FIGURE  4-6  (Concluded) 
SET  UP  SEGMENT  SCAN 


ROUTINE  Scan_Segment_To_Pick_Up_Cells ; 

PARAMETERS 
SEGMENT  IN, 

Box  IN, 

Last_Box  IN, 

Slope  IN, 

Step_X  IN, 

Step_Y  IN, 

Indep_Var  IN, 

GRID  CHAIN  CELLS  INPUT: 

REFER  Tft  GLOBAL 

ENVIRONMENTALjCELLS ; 

REFER  TO  SHARED  LOCAL 
SEGMENTS  IN; 

DEFINE  TABLES 
SEGMENT 
begin_x 
begin_y 
begin_z 
begin_t 
end_x 
end_y 
end_z 
end  t 


The  current  trajectory  segment 
The  first  cusp  of  the  segment 


The  second  cusp  of  the  segment 


GRID_C  HAINjCELLS 
cell_id 

f ir8t_cusp_t ime 


The  cells  intersecting  the  trajectory 
The  cell  identifier 
The  time  of  the  first  cusp  before  the 
cell; 


DEFINE  VARIABLES 
Box 

Las  t_Box 
Slope 

Step_X 

StepY 

IndepVar 

Prv_Box 

Prv_Box_X 

Prv_Box_Y 

Box_X 

Box_Y 

Step_Count 

X 

Y 


The  first  cell  intersected 
The  last  cell  Intersected 

The  slope  of  the  segment  with  respect  to  the 
independent  variable 
The  independent  variable  increment 
The  independent  variable  increment 
The  independent  variable 
The  previous  cell  intersected 
The  minimum  X  value  of  the  previous  cell 

The  minimum  Y  value  of  the  previous  cell 

The  minimum  X  value  of  the  current  cell 

The  minimum  Y  value  of  the  current  cell 

The  number  of  independent  variable  steps 
The  X  coordinate  of  the  current  step 
The  Y  coordinate  of  the  current  step; 


FIGURE  4-8 

SCAN  SEGMENT  TO  PICK  UP  CELLS 
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Step_Count  “  0; 

REPEAT  WHILE  Box  NE  Last_Box; 
Step_Couni  ■  Step  Count  +  1; 
Prv_Box  =  Box; 

SELECT  FI)  LDS  min  x,min_y 


FROM  ENVIRONMENTAL  CELLS 


INTO  X • Y 


WHERE  '  NVIRONMKNTAL_CELLS . cell_id  E£  Prv_Box; 
J_F  IndepJ  ar  E£  "X" 

THEN 


X  -  X  +  Step_X; 

Y  *  SEGMENT. beg in_y  +  Slope  *  Step_Count; 
CALL  Grid  (X  IN,  Y  IN,  Box  OUT) ; 

SELECT  FIELDS  min  y 


FROM  ENVIRONMENTAL  CELLS 


INTO  Prev  Box  Y 


WHERE  ENVIRONMENTAL_CELLS.cell_id  E£  Prv_Box; 
SELECT  FIELDS  min_y 

FROM  ENVIRONMENTAL  CELLS 
INTO  Box  Y 


WHERE  ENV IR ONME NTAL_C ELLS . c e 1  l_i d  Box; 

IF  Box  Y  NE  Prv_Box_Y 
THEN 


ELSE 


CALL  Add_Box  (Prv_Box  IN,  Box  IN,  SEGMENT  IN, 
GRID  CHAIN_C ELLS  INPUT); 


Y  -  Y  +  Step  Y; 

X  ■  SEGMENT. beg in_x  +  Slope  *  StepjCount; 
CALL  Grid  (X  IN,  Y  IN,  Box  OUT); 

SELECT  FIELDS  min  x 


FROM  ENVIRONMENTAL_CELLS 
INTO  Prv_Box_X 

WHERE  ENV IR  ONME  NTAL_C ELLS. cel l_id  E£  PrvBox; 
SELECT  FIELDS  min  x 


FROM  ENV IRONMENTAL_CELLS 
INTO  Box  X 


WHERE  ENV IR ONME NTAL_CELLS .cell_id  E£  Box; 
IF  Box_X  NE  Prv_Box_X 
THEN 


CALL  Add  Box  (Prv_Box  IN,  Box  IN,  SEGMENT  IN, 
GRID_CHAIN_CELLS  INPUT); 

INSERT  INTO  GR I D_C HA I N_C ELLS 

Tcell_id  =  Box,  f lrst_cusp_tlme  =*  SEGMENT. begin_t) ; 
END  Scan_Segment_To_Pick_Up_Cells ; 


FIGURE  4-8  (Concluded) 
SCAN  SEGMENT  TO  PICK  UP  CELLS 
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ROUTINE  Add_Box; 

PARAMETERS 

PrevBox  IN, 

Box  IN, 

SEGMENT  IN, 

GRID  CHAIN  CELLS  INOUT; 

DEFINE  TABLES 
SEGMENT 
beginjx 
begin~y 
begln_z 
begin_t 
end_x 
end_y 
end_z 
end_t 

GRIDJCHAINJCELLS 

cell_id 

f ir8t_cuap_t ime 

DEFINE  VARIABLES 
Prev_Box 
Box 

Prev_Box_X 

Prev_Box_Y 

Box_X 

Box_Y 

Side 


The  current  trajectory  segment 
The  first  cusp  of  the  segment 


The  second  cusp  of  the  segment 


The  cells  which  interseot  the  trajectory 
The  cell  identifier  1 

The  time  of  the  first  cusp  before  the 
cell; 

The  previous  cell  intersected 
The  current  cell  intersected 
The  minimum  X  value  of  the  previous  cell 

The  minimum  Y  value  of  the  previous  cell 

The  minimum  X  value  of  the  current  cell 

The  minimum  Y  value  of  the  current  cell 

The  side  of  the  line  where  the  point  is; 


FIGURE  4-9 
ADD  BOX 


CALL  Get  Lower  Left  Corner  Points  (Prev  Box  IN,  Box  IN, 
Prev_Box_X  OUT,  Prev_Box_Y  OUT,  Box_X  OUT,  Box_Y  OUT); 

CHOOSE  CASE 

WHEN  Box_X  GT  Prev_Box_X  AND  Box_Y  GT  Prev_Box_Y  THEN 

_ CALL  Lineal,  Discriminant  class  1  tier  btCKEKTi oCgie — - - 

IN,  SEGMENT. end  IN,  Box  X  IN,  Box_Y  IN,  Side  OUT) 

IF  Side  E£  "left" 

THEN 

*  ,  CALL  Pu t_Box_In_Gr id_Chain  (Prev_Box_X  IN, 

Box_Y  IN*  SEGffiNT  IN,  GfUD_CHAIN_CELLS  INPUT); 

.  EtSE 

CALL  Pu t_Box_In_.Gf id^Ghain .  (Box  .IN,.  Ptev_Box_Y  IN, 
SEGMENT  IN ,  GRID_C HAINjG ELL’S ,  INPUT) ; 

WHEN  Box_X  GT  PrevBoxX  AND  BOx_Y  LT  Prev_Box_Y  THEN 
CALL  Linear  Discriminant  Classifier  (SEGMENT. begin  IN, 
SEGMENT. end  IN,  Box_X  IN,  Prev_Box_Y  IN,  aide  OUT) 

’  IE  Side  E£  "left" 

THEN 

CALL  Put  Box  In  Grid  Chain  (Box  X  IN,  Prev  Box  Y  IN, 
SEGMENT  IN,  GRID_CHA1N_CELLS  INPUT); 

ELSE 

CALL  Put_Box_In_Grid_Chain  (Prev_Box_X  IN, 

Box_Y  IN,  SEGMENT  IN,  GRID_CHAIN_CELLS  INPUT); 

WHEN  Box_X  LT  Prev_Box_X  AND  Box_Y  GT  Prev_Box_Y  THEN 
CALL  Linear  Discriminant  Classifier  (SEGMENT. beg in  IN, 
SEGMENT. end  IN,  Prev_Box_X  IN,  Box_Y  IN,  Side  OUT?; 

IF  Side  E£  "left" 

THEN 

CALL  Pu t_Bo x_I n_Gr 1 d_Chain  (Box_X  IN,  Prev_Box_Y  IN, 
SEGMENT  IN,  GRID  CHAIN  CELLS  INPUT); 

ELSE 

CALL  Put_Box_In_Grid_Chain  (Prev_Box_X  IN,  Box_Y  IN, 
SEGMENT  IN,  GRID_CHAIN_CELLS  INPUT); 

WHEN  Box_X  LT  Prev_Box_X  AND  Box_Y  LT  Prev_Box_Y  THEN 
CALL  Linear_Discriminant_Classif ier  ( SEGMENT. begin  IN, 

SEGMENT. end  JN,  Prev_Box_X  IN,  Prev_Box_Y  IN,  Side  OUT) 
IF  Side  E£  "left" 

THEN 

CALL  Put_Box_In_Grid_Chain  (Prev_Box_X  IN, 

Box_Y  IN,  SEGMENT  IN,  GRID_CHAIN_CELLS  INPUT); 

ELSE 

CALL  Pu t_Box_I n_Grid_Chain  (Box_X  IN,  Prev_Box_Y  IN, 
SEGMENT  IN,  GRIDCHAINCELLS  INPUT); 

END  Add  Box; 


FIGURE  4-9  (Concluded) 
ADD  BOX 
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(a)  Independent  variable  is  x  and  no  change  in  y 
therefore  no  intermediate  grid  cell. 


(b)  Independent  variable  is  x  and  a  change  in 
y  of  +1  (grid  cell  coordinates)  indicates 
an  intermediate  box  is  intersected  (in 
dashed  lines). 


FIGURE  4-10 

INTERMEDIATE  GRID  CELL  RECOGNITION 


ROUTINE  Get_Lower_Lef t_Corner_Points; 
PARAMETERS 

PrevJBox  in, 

Box  IN, 


PrevBoxX  OUT, 
Prey_Box_Y  OUT, 
Box_X  OUT, 

Box_Y  OUT; 

REFER  TO  GLOBAL 


ENVIRONMENTAL  CELLS 
DEFINE  VARIABLES 

IN; 

Prev  Box 

The 

Box 

The 

Prev  Box  X 

The 

Prev  Box  Y 

The 

Box  X 

The 

Box  Y 

The 

## 


previous  cell  Intersected 

current  cell  Intersected 

minimum  X  value  of  the  previous  cell 

minimum  Y  value  of  the  previous  cell 

minimum  X  value  of  the  current  cell 

minimum  Y  value  of  the  current  cell; 


SELECT  FIELDS  min_x,min_y 
FROM  ENVIRONMENTALJCELLS 
INTO  Prev_Box_X ,  Prev_Box_Y 
WHERE  ENVIRONMENTALJCELLS . cell_id  E£  Prev_Box; 
SELECT  FIELDS  min_x,mln_y 
FROM  ENV IRONMENTAL_CELLS 
INTO  Box_X,  Box_Y 

WHERE  ENVIRONMENTAL_CELLS .celi_id  E£  Box; 

END  GetLower  Left  Corner_Points ; 


FIGURE  4-12 

GET  LOWER  LEFT  CORNER  POINTS 
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ROUTINE  Pu  t_Box_I  n_Gr i d_Cha i n ; 

PARAMETERS 

X  IN, 

Y  IN, 

SEGMENT  IN, 

GRIDjCHAINjCELLS  INPUT; 

DEFINE  TABLES" 

SEGMENT  The  current  trajectory  segment 

begin_x  The  first  cusp  of  the  segment 

begin_y 
begin_z 
begin_t 

end_x  The  second  cusp  of  the  segment 

end_y 

end_z 

end  t 


GRIDJCHAINJCELLS 

cell_id 

f Irst_cusp_t ime 


The  cells  intersecting  the  trajectory 
The  cell  identifier 
The  time  of  the  first  cusp  before  the 
cell; 


DEFINE  VARIABLES 
X 
Y 

Cell  Id 

## 


The  X  coordinate  of  the  point 
The  Y  coordinate  of  the  point 
The  cell  which  includes  the  point  (X,Y); 


CALL  Grid  (X  IN,  Y  IN,  Cell_Id  OUT); 

INSERT  INTO  GRID _CHAIN_C ELLS 

(cell_id  *  Cell_Id,  first_cusp_time  *  SEGMENT. beg in_t); 
END  Put_Box_In  Grid_Chain; 


FIGURE  4-13 
PUT  BOX  IN  GRID  CHAIN 
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4.2.1  Mission 


First-Order  Coarse  Filter  processing  has  identified  a  set  of 
Nominee  polygons.  The  Second-Order  Coarse  Filter  is  a  finer 
filter  which  processes  the  First-Order  Nominee  polygons  to 
reduce  the  set  of  potentially  intersecting  polygons.  At  this 
level  of  granularity,  "dose"  is  defined  so  as  to  include  only 
those  nominee  polygons  (approximated  by  the  smallest  right 
rectangle  aligned  square  to  the  coordinate  axes)  which  inter¬ 
sect  the  trajectory  segments.  The  polygons  passing  this  filter 
are  examined  in  greater  detail  in  the  Fine  Filter. 

4.2.2  Design  Considerations  and  Component  Environment 

In  the  Second-Order  Coarse  Filter,  the  algorithm  accesses,  for 
the  first  time  in  Airspace  Probe,  the  actual  dimensions  of  the 
four-dimensional  polygons.  However,  the  polygons,  themselves, 
are  not  processed,  but  enclosed  in  a  parallelepiped.  The 
extents  in  the  x,  y,  z,  and  t  dimensions  are  used  to  construct 
the  parallelepiped  (Figure  4-14).  One-dimensional  Intersection 
tests  alone  on  this  volume  rapidly  eliminate  non-candidate 
polygons,  especially  those  not  intersecting  the  trajectory  in 
the  altitude  and  time  dimensions  (dimensions  not  incorporated 
into  the  First-Order  Coarse  Filter). 

The  sequence  of  elements  associated  with  the  Second-Order 
Coarse  Filter  is  given  in  Figure  4-15.  Program  design  language 
is  provided  in  this  section  for  each  element  of  Figure  4-15 
with  the  exception  of  Linear_Discriminant_Classifier.  A 
description  of  that  element  is  provided  in  Appendix  B. 

Input  Data 

The  input  data  required  by  the  Second-Order  Coarse  Filter 
consists  of: 
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<£  '  i  '  .  »  • 

*  .  •  .  •  .  -  .  *  » • 

Set  on  d_Ordelr_C#ar  8  e_Fil  te  t  .•*.  •  * '  . 

.  Retxlev4^Polygon_Extenrtd  c  '  ° 

0ne_DiaJChcck8  *  -  . .  . 

‘  Segaent_V8_Segaent_Intersectioh  .  • 

.  Two__Dim_Checks 

Segnent_V8_Plane_lntersecfclon 
Lines  r_M.  scrim!  nan  t_Class if i er 


FIGURE  4-15 

ELEMENTS  OF  THE  SECCND-GRDER  COARSE  FILTER 


•  System  Global  Data  Base 

-  SPECIAL_USE_AIRSPACES 

The  activation  and  deactivation  times  associated 
with  individual  polygons  are  retrieved  to  support 
rime  interval  intersection  tests. 

-  VOLUME  JCOORDINATES 

The  (x,y)  coordinates  of  each  vertex  of  each  polygon 
are  contained  in  this  table.  Only  the  maximum  and 
minimum  x’s  and  y's  are  obtained.  The  celling  and 
floor  altitudes  for  the  polygon  are  used  to  describe 
the  vertical  extent. 

•  Shared  Local  Data  Base 

-  SEGMENTS 


The  aircraft's  trajectory  has  been  stored  for 
Airspace  Probe  use  as  an  ordered  sequence  of  line 
segments.  Each  trajectory  segment  is  checked  for 
possible  intersection  with  parallelepipeds 
containing  First-Order  Nominees. 

FIRST_ORDER_NOMINEES 

This  table  contains  the  identity  of  each  polygon 
thought  to  be  "close"  to  the  trajectory. 


Output 


The  Second-Order  Coarse  Filter  produces  a  list  of  nominee 
polygons  which  must  be  processed  through  the  remainder  of  the 
Airspace  Probe  algorithm. 


•  Shared  Local  Data  Base 


-  SECOND_ORDER_NOMINEES 

The  identities  of  the  polygons  which  are  identified 
by  the  Second-Order  Coarse  Filter  are  stored  in  this 
table.  These  polygons  must  have  the  property  that  a 
parallelepiped  enclosing  the  volume  intersects  the 
trajectory  of  the  aircraft. 
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4.2.J  Component  Design  Logic 


The  Second-Oi ler  Coarse  Filter  (Figure  4-16)  examines  each 
First-Order  Nominee  to  determine  if  an  intersection  can  exist 
with  the  ai  craft  trajectory.  Each  nominee  is  processed 
separately,  f  rst  by  obtaining  the  maximum  and  minimum  x,  y,  z, 
and  t  values  .cross  the  polygon.  This  first  step  is  performed 
by  the  element  Retrieve_Polygon_Extents  (Figure  4-17). 

Each  trajectory  segment,  beginning  with  the  cusp  associated 
with  the  nominee,  Is  examined  for  potential  intersections. 
Each  segment  passing  through  the  process  undergoes  tests 
against  the  rectilinear  space  circumscribed  about  the  polygon 
being  checked.  To  perform  this  test,  a  sequence  of  filtration 
steps  are  performed.  The  two  major  steps  check  If  the  aircraft 
trajectory  segment  Intersects:  (1)  the  extent  of  the  polygon 
In  single  dimensions  (Figure  4-18) ,  and  (2)  the  extent  of  the 
polygon  in  certain  planes  (Figure  4-19).  If  an  intersection  Is 
not  found  at  any  particular  step,  the  aircraft  trajectory  will 
not  intersect  the  polygon.  Consequently,  the  polygon  is 
rejected  as  a  Nominee  immediately  if  this  condition  is  detected. 

The  first  step,  given  in  the  element  One_Dim_Checks  (Figure 
4-20),  sets  up  comparisons  of  the  aircraft  trajectory  segment 
with  the  extent  of  the  polygon.  The  comparisons  done  in 
Segment_V8_Segment_Intersection  (Figure  4-21)  check  to  see  if 
the  1-dimensional  extent  of  the  trajectory  segment  intersects 
the  1-dimensional  extent  of  the  polygon  in  corresponding 
dimensions.  The  order  in  which  dimensions  are  checked  should 
be  ordered  in  such  a  way  as  to  take  advantage  of  the 
distribution  of  trajectory  segment  and  polygon  data.  For 
example,  if  most  aircraft  trajectory  segments  input  to  the 
Second-Order  Coarse  Filter  indicate  that  checking  the  altitude 
would  drop  half  the  cases  but  checking  one  of  the  horizontal 
dimensions  would  drop  only  a  quarter  of  the  cases,  then  the 
altitude  check  should  be  made  before  the  horizontal  checks. 

The  second  step,  given  in  the  element  Two_Dim_Checks  (Figure 
4-22),  sets  up  comparisons  of  the  extent  of  the  aircraft 
trajectory  to  the  extent  of  the  polygon  in  various  orientation 
planes.  The  comparisons  done  in  Segment_Vs_Plane_Intersection 
(Figure  4-23)  check  to  see  if  the  2-dimensiotal  extent  of  the 
trajectory  segment  intersects  the  2-dimensional  extent  of  the 
polygon.  Only  the  x-y,  y-z,  x-z,  and  z-t  planes  are  examined. 
It  is  not  necessary  to  check  the  x-t  and  y-t  planes  or  the 
x-y-z  volume  since  the  planes  checked  account  for  these 
orientations.  The  Second-Order  Coarse  Filter  examines  the 
polygon  from  the  various  orientation  planes  in  this  coarse 
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ROUTINE  Second_Order_Coarse_Filter; 

REFER  TO  SHARED  LOCAL 
SEGMENTS  IN, 

FIRST_ORDER_NQMINEES  IN, 
SECOND_ORDER_NOMINEES  OUT; 

DEFINE  TABLES 

PQLYGON_EXTENTS  The  extents  of 

dimension 


min_x 
min_y 
min_z 
min  t 


The  minimum 
The  minimum 
The  minimum 
The  minimum 


the  polygon  in 

value  of  the  x 
value  of  the  y 
value  of  the  z 
value  of  the  t 


each 

dimension 

dimension 

dimension 

dimension 


max_x 

max_y 

max_z 

max_t 

DEFINE  VARIABLES 


The  maximum  value  of 
The  maximum  value  of 
The  maximum  value  of 
The  maximum  value  of 


the  x  dimension 
the  y  dimension 
the  z  dimension 
the  t  dimension; 


§egment_Intersection  This  flags  a  segment  Intersection 
Plane  Intersection  This  flags  a  plane  intersection; 

##  " 

REPEAT  FOR  EACH  F IRST_QRDER_NOMINEES  RECORD; 

CALL  Re  t  r  1  e  ve_Polyg  on_ExFent  s 

TFIRST_ORDER_NOMINEES.volume_ld  IN,  P0LYG0N_EXTEN1S  OUT); 
REPEAT  FOR  EACH  SEGMENTS  RECORD 


WHERE  SEGMENTS. begln_time  GE 

FIRST_ORDER_NOMINEES . f lrst_cusp_tlme  AND 
FIRST_ORDER_NOMINEES .volumeid  IS  NOT  IN 
SEC  ON  D_ORDER_N  OKI NEE . volume_i d ; 

CALL  One_Dlm_Checks  ( SEGMENTS . pair  IN,  POLYGON_EXTENTS  IN, 

Segment_Intersection  OUT); 

IF  Segment_Intersection  E£  "true" 

THEN 

CALL  Two_Di m_Ch e ck s  (SEGMENTS .pair  IN, 

POLYGON_EXTENTS  IN,  Plane_Intersectlon  OUT); 

IF  Plane_Inter8ectlon  EQ  "true" 

THEN 

INSERT  INTO  SECOND_ORDER_NOMINEES 
(all  -  FIRST_ORDER_NOMINEES .all) ; 

END  Second_Order_Coarse_Filter; 


FIGURE  4-16 

SECOND  ORDER  COARSE  FILTER 
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Vi 


ROUTINE  Retrieve  Polygon  Extents; 
PARAMETERS 

Volume_Id  IN, 

PQLGONEXTENTS  OPT; 

REFER  TO  GLOBAL 

SPECIAL  USE_AIRSPACES  IN, 

volume  Coordinates  in: 


the  polygon  In 

value  of  the  X 
value  of  the  Y 
value  of  the  Z 
value  of  the  T 
value  of  the  X 
value  of  the  Y 
value  of  the  Z 
value  of  the  T 


DEFINE  TABLES 

POLYGON_EXTENTS 

min_x 

min_y 

min_z 

min_t 

max_x 

max_y 

max_z 

max_t 

DEFINE  VARIABLES 


The  extents  of 
dimension 
The  minimum 
The  minimum 
The  minimum 
The  minimum 
The  maximum 
The  maximum 
The  maximum 
The  maximum 


each 

extent 
extent 
extent 
extent 
extent 
extent 
extent 
extent ; 


Volume_Id 
Start_Time 
Stop_Time 
DEFINE  CONSTANTS 


The  volume  identifier 

The  activation  time  of  the  polygon 

The  deactivation  time  of  the  polygon; 


Earlie8t_Possible_Time  The  earlist  representable  time 

Latest  Possiblejrime  The  latest  representable  time; 


FIGURE  4-17 

RETRIEVE  POLYGON  EXTENTS 


IF  Volume_Id  IS  IN  SPECIALISE  AIRSPACES  .volume_id 
THEN 

SELECT  FIELDS  8tart_time,stop_time 
FROM  SPECIAL_USE_AIRSPACES 
INTO  StartJTime.StopJTime 

WHERE  SPECIAL_USE_AIRSPACES.volume_id  EQ  Volume_Id; 
EIEE  #  Volume  Id  must  be  for  an  E-MSAW  area  # 

StartJTime  “  Earliest_Po88ible_Time; 

Stop_Time  *  Latest_Possible  Time; 

INSERT  INTO  PGLYGON_EXTENTS 

(min_lT  “  StartJTime,  max_t  "  StopJTlme); 

UPDATE  IN  POLYGON_EXTENTS 

(mln_x  “  VOLUME  COORDINATES .x) 

WHERE  VQLUME_COORDINATES  .volume  Id  E£  Volume  Id  AND 

VOLUME_C OORDI NATES  .x  jg  MIN  IVOLUME_COORDINATES  .x)  AND 
P OLY GON_EXTENTS . mln_t  Eg  Start  Time! 

UPDATE  IN  PQLYGON_EXTENTS 

(max  x  -  VOLUMEjCOORDINATES .  x) 

WHERE  VOLUMEjCOORDINATES  .volume  Id  Eg  Volume_Id  AND 

VOLUME_COORDINATES . x  Eg  MAX  TvOLUME  COORDINATES.x)  AND 
POLYGONEXTENTS .mln_t  W  Start_Tlme; 

UPDATE  IN  POLYGON_EXTENTS 

(minjr  -  VOLUME  COORDINATES . y) 

WHERE  VOLUMEjCOORDINATES  .volume_id  Eg  Volume_Id  AND 

VOLUMEjCOORDINATES .y  Eg  MIN  ( VOLUMEjCOORDINATES. y)  AND 
P OLY GON_EX TENTS . mln_t  Eg  Start_Tlme7 
UPDATE  IN  POLYGON_EXTENTS 

(max_y  -  VOLUME_COORDINATES.y) 

WHERE  VOLUMEJCOORDINATES .volume  id  Eg  Volume_Id  AND 

VOLUMEJCOORDINATES. y  Eg  MAX  7V0LUME  COORDINATES. y)  AND 
POLYGONJEXTENTS . min_t  Eg  Start  Time; 

UPDATE  IN  PGLYGON_EXTENTS 

(min_z  ■  VOLUMES. floor_altitude) 

WHERE  VOLUMES. volume_id  Eg  Volume_Id  AND 
POLYGON_EXTENTS .min_t  Eg  Start  Time; 

UPDATE  IN  PQLYGONjEXTENTS 

fmaajz  “  VOLUMES. ceiling_altitude) 

WHERE  VOLUMES. volume  id  EQ  Volume  Id  AND 
POLYGON_EXTENTS . min_t  Eg  StartJTime; 
l  Re  trie ve_Polygon_Extent  s ; 


FIGURE  4-17  (Concluded) 
RETRIEVE  POLYGON  EXTENTS 


FIGURE  4-18 

TRAJECTORY/POLYGON  ONE-DIMENSIONAL  INTERSECTION 
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FIGURE  4-19 

TRAJECTORY/POLYGON  TWO-DIMENSIONAL  INTERSECTION 


ROUTINE  One_Dim_Checks; 

PARAMETERS 
SEGMENT  IN, 

POLYGON_EXTENT  IN, 

Segment_Intersection  In_All_Dimensiona  OUT; 

DEFINE  TABLES 

The  current  trajectory  aegaent 
The  first  cusp  of  the  segment 


SEGMENT 
begin_x 
begin_y 
begin_z 
begin_t 
end_x 
end_y 
end_z 
end_t 

POLYGON  EXTENT 


The  second  cusp  of  the  segment 


The  extent  of  the  polygon  In  each 


dimension 

min_x 

The 

minimum  value 

of 

the 

X 

extent 

min_y 

The 

minimum  value 

of 

the 

Y 

extent 

min_z 

The 

minimum  value 

of 

the 

Z 

extent 

min_t 

The 

minimum  value 

of 

the 

T 

extent 

max_x 

The  maximum  value 

of 

the 

X 

extent 

max_y 

The 

maximum  value 

of 

the 

Y 

extent 

max_z 

The 

maximum  value 

of 

the 

Z 

extent 

max  t 

DEFINE  VARIABLES 

The 

maximum  value 

of 

the 

T 

extent 

Segment_Inter8ection_In_All_DimensIons 
Segment  Intersection 


Flag 

Flag; 


FIGURE  4-20 
ONE  DIM  CHECKS 


Segnent_IntersectIon_In_All_Dimension8  “  "false"; 

CALL  Segaent_Vs_Segnent  Intersection  ( SEGMENT . begin_t  IN, 
SEGMENT.  end_t  IN,  P OL Y GON_EXTENT . nin_t  IN, 

POL YGON_EXT ENT . na x_t  EM,  Segnent_Intersectlon  OUT); 

IF  Segoent_Intersectlon  E^  "true" 

THEN 

CALL  Segment_Vs_Seg«ent_Intersection  ( SEGMENT. begin_z  IN, 
SEGMENT. end_z  IN,  P QLYGON_EXTENT . nin_z  IN, 
PGLTGON_EXTENT.naz_z  IN,  Segaent_Intersection  OPT); 

IF  Segmentlntersection  E§  "true" 

THEN 

CALL  Segnent_Vs_Segment_Intersection  ( SEQUENT . begin_x  IN, 
SEGMENT. endx  IN,  P0LYGON_EXTENT ,min_x  IN, 
POLYGON_EXTENT. max_x  IN,  Segment_Intersection  OPT); 

IF  Segment_Intersection  E£  "true" 

THEN 

CAT.T,  Segment_Vs_Segment  Intersection 

(SEGMENT. beg I n_y  IN, “SEGMENT. end_y  IN, 
POLYGON_EXTENT.min_y  IN,  POLYGON_EXTENT . max_y  IN, 
Segment__Intersection  OPTTr 
IF  Segnent_Inter8ectlon  EQ  "true" 

THEN 

Segment_Inter8ection_In_All_Dinension8  “  "true"; 

END  OneDim  Checks; 


FIGURE  4-20  (Concluded) 
ONE  DIM  CHECKS 


ROUTINE  Segment  Vs  Segment  Intersection; 

PARAMETERS 

Segment_Mlnlmum  IN, 

Segnen t_Ma»lmum  IN, 

Polygon_Minlmum  IN, 

Polygon_Maximum  IN, 

Segment  Intersection  OPT; 

DEFINE  VARIABLES 

Segment_Minlaum  The  minimum  value  of  the  segment  extent 

for  a  given  dimension 

Seguent_Maxlmum  The  maximum  value  of  the  segment  extent 

for  a  given  dimension 

Polygon_Mlnimum  The  minimum  value  of  the  polygon  extent 

for  a  given  dimension 

Polygon_Maximum  The  maximum  value  of  the  polygon  extent 

for  a  given  dimension 

Segment  Intersection  The  flag  for  a  segment/polygon  intersection 

## 

IF  Segment_Mlnlmum  GT  Polygon_Maxlmum  OR 
Segment_Maxlmum  LT  Polygon_Minimum 
THEN 

Segment  Intersection  "  "false"; 

ELSE 

Segment_Intersectlon  ■  "true"; 

END  Segment_Vs_Segment_Inter section; 


FIGURE  4-21 

SEGMENT  VS  SEGMENT  INTERSECTION 


ROUTINE  Two  Dim_Checks; 

PARAMETERS 
Segjcnt  IN, 

PCLYGON_EXTENT  IN, 

Plane_Intersection  In_All  Orientations  OUT; 

DEFINE  TABLES 

SEGMENT  The  current  trajectory  segment 

begin_x  The  first  cusp  of  the  segment 

beginjr 

begin_z 

begin_t 

end_x  The  second  cusp  of  the  segment 

end_y 

endjB 

end_t 

PQLYGON_EXTENT  The  extent  of  the  polygon  in  each 

dimension 

mln_x  The  minimum  value  of  the  X  extent 

aln_y  The  minimum  value  of  the  Y  extent 

mln_z  The  minimum  value  of  the  Z  extent 

min_t  The  minimum  value  of  the  T  extent 

max_x  The  maximum  value  of  the  X  extent 

max_y  The  maximum  value  of  the  Y  extent 

max_z  The  maximum  value  of  the  Z  extent 

max  t  The  maximum  value  of  the  T  extent; 

DEFINE  VARIABLES 

Plane_Intersection_In_All_Orientations  Flag 
Plane_Inter8ec  t ion”  Flag ; 


FIGURE  4-22 
TWO  DIM  CHECKS 


Plane_Intersection_In_All_0rlentation8  -  "false"; 

CALL  Segaent  Vs  Plane- Intersection  (SEGMENT. begin  t  IN, 
SEGMENT. begin  z  InT  SEGMENT. end  t  IN,  SEGMENT .end  z  IN, 
PQLYGON_KXTENT . nin  t  IN,  POLYGON  EXTENT. max  t  IN,“ 
POLYGON- EXTENT . ainje  IN,  PCLYGCN-EXTENT . Bax-t  Iff, 

Plane  Intersectlon~OOfT; 

IP  Plane_Intersectlon  E(£  "true" 

THEN 

CAIJ.  Segaent  Vs  Plane  Intersection  (SEGMENT. begin  x  IN, 
SEGMENT. begin  z  IN,  SEGMENT. end  x  IN,  SEGMENT .end_s  IN 
POLYGONKXTENT . aln  x  IN,  POLYGON  EXTENT. aax_x  IN, 
PCLYGON_EXTENT . ain“r  IN,  POLYGON- EXTENT.aaxa_x  IN, 

Plane  Intersection- POTT s  - 

IP  Plane_Intersection  EQ  "true" 

THEN 

CAUL  Segaent  Vs_Plane_Intersection  ( SEGMENT . beginjr  IN 
SEGMENT. beginjs  IN,  SBGMENT.endjf  a, 

SEGMENT. end  s  IN,  POLYGON_EXTENT.alnj  IN, 
POLYCON_gXTENT.aaxjr  IN,  POLYGCN_EXTENT.ain*  a, 
POLYGON_EXTENT . aax_s  a,  Plane_Intersection  OUfT ; 

IP  Plane  Intersection- EQ~~ "true" 

THEN 

CALL  Segaent  Vs_Plane  Intersection 

TSEGMENT .begin  x  IN,  SEGMENT. begin_y  IN, 

SEGMENT. end  x  IN,  SEGMENT,  endjy  IN, 

POLYGON  EXTENT. Bin  x  IN,  POLYGON  EXTENT. aax  x  IN 
POLYGON- EXTENT . ninjr  a,  POLYGON- EXTENT . aax^  IN 
Plane_Intersectlon  PUTT; 

IP  Plane- Intersection  E^  "true" 

THEN 

Plane_Intersectlon_In_All_Orientations  -  "true"; 
END  Two  Dla  Checks; 


FIGURE  4-22  (Concluded) 
TWO  Da  CHECKS 


ROUTINE  Segaent  Vs  Plane  Intersection; 
PARAMETERS 


Segaent_Start_U  IN, 

Segaen t_S ta r  t_V  IN, 
Segaent  End_U  IN, 

Segaent- Bid  V  IN, 
Polygon- MlhTaun_U  IN, 
Polygon~Mlnlaua~V  IN, 
Polygon_Msxlaua_U  IN, 
Polygon_Maxiau «_V  IN; 
Segaent_Interaectlon  OPT; 

DEFINE  VARIABLES 


Segaent_Start_U 

Se  gment_Start_V 

Segment_End_U 

Segment_End_V 

Polygon_Mlnlaua_D 

Polygon_MIniaua_V 

Polygon- MaxinmmJJ 

Polygon_Maxlmun_V 

Plane_Intersectlon 

Fir8t_Slde 

Side 


The  value  of  the  U  coordinate  for  the 
first  cusp  of  the  segaent 
The  value  of  the  V  coordinate  for  the 
first  cusp  of  the  segaent 
The  value  of  the  U  coordinate  for  the 
second  cusp  of  the  segaent 
The  value  of  the  V  coordinate  for  the 
second  cusp  of  the  segaent 
The  alnlaua  U  extent  of  the  polygon 
The  alnlaua  V  extent  of  the  polygon 
The  aaxlaua  U  extent  of  the  polygon 
The  aaxlaua  V  extent  of  the  polygon 
The  segaent/plane  Intersection  flag 
The  side  of  the  segaent  on  which  the 
first  polygon  vertex  lies 
The  side  of  the  segaent  on  which  the 
current  polygon  vertex  lies; 


FIGURE  4-23 

SEGMENT  VS  PLANE  INTERSECTION 
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Plane_Intersection  “  "true"; 

CAIJ.  Linear_M.8crielnant_ClaBSifi.er  (SegaentjStartJU  IN, 
Segaent_Start_V  IN,  Segaent_Ead_U  IN,  Segiaent_End_V  IN, 
Polygon_Minieue_0  IN,  Polygcm_Miniiiun_V  IN,  Flrst_Slde  OPT); 
c*t.t.  Linear_Mscrieinant_Clas8ifier  (Segaent  Start  U  IN, 

Segment  Start  V  IN,  Segaent  End  U  IN,  Segaent_End_V  IN, 
Polygon_Maxiaum_U  IN,  Polygon  Mlnlaua_V  IN,  Side  ODtTT 
IP  Side  First  Side 
THEN 

CALL  Llnear_Mscrlalnant_Cla8aifier  (Segaent_Start_U  IN,. 
SegnentJstart_V  IN,  Segaent_End_U  IN,  Segaent_End_V  IN, 
Polygon_Maxlaua_U  IN,  Polygon_NaxlauB_V  IN,  Side  OUTTT 
IF  Side  BgfFlxst  Side 
THEN 

CALL  Llnear_DlscrlalnantjClaaalfler  ( Segaent_S tar t_U  IN, 
Segaen  t_Start_V  IN,  Segaent_End_U  IN,  Segaent_End_V  IN, 
Polygon  Mlnlaua  U  IN,  Polygon  Maxiaua  V  IN,  Side  OUrTT 
IF  Side  ECfFlrst  Side 
WEN 

Plane_Intersectlon  “  "false"; 
i  Segaent_Vs_Plane_Intersectlon; 


FIGURE  4-23  (Concluded) 
SEGMENT  VS  PLANE  INTERSECTION 
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manner.  The  entire  polygon  is  not  examined  but  rather  the 
smallest  rectilinear  space  square  to  the  coordinate  axes 
circumscribed  about  it. 


To  determine  whether  a  segment  intersects  a  given  rectangle 
coarsely  describing  the  extent  of  the  polygon  in  a  certain 
orientation  plane,  a  linear  discriminant  is  used.  The  Linear_ 
Discriminant_Classif ier  is  described  in  Appendix  B.  With  the 
information  it  provides  ,  one  can  classify  points  in  the 
orientation  plane  as  being  left  or  right  of  the  trajectory 
segment.  A  trajectory  segment  will  intersect  the  rectangle 
about  the  polygon  extent  (in  a  given  plane)  if  points  of  the 
polygon  are  found  both  to  the  left  and  to  right  of  the  segment 
(i.e.  a  line  of  the  rectangle  must  cross  the  segment). 

4.3  Fine  Filter  Processing 

4.3.1  Mission 


The  Second-Order  Coarse  Filter  processing  has  Identified  a  set 
of  Nominee  polygons  that  are  close  to,  but  do  not  necessarily 
intersect,  the  aircraft's  trajectory.  The  Fine  Filter 
processing  now  must  determine  whether  the  given  polygons  do 
Indeed  intersect  the  aircraft's  trajectory.  The  processing  for 
each  polygon  is  more  involved  than  that  in  the  coarse  filters 
since  the  polygons  may  have  concave  sides  and  the  exact  points 
of  intersection  in  4-space  must  be  determined.  The  Information 
found  by  the  Fine  Filter  is  passed  on  to  Encounter  Processing 
to  set  up  the  relevant  global  data  structures. 

4.3.2  Design  Considerations  and  Component  Environment 

In  the  Fine  Filter,  the  coordinates  of  the  vertex  points  of 
each  Second-Order  Nominee  are  used  to  construct  line  segments 
to  test  for  intersection  with  a  trajectory  segment.  For 
efficiency  reasons,  the  logic  should  consider  convex  and 
nonconvex  polygons  separately. 

The  sequencing  of  elements  associated  with  the  Fine  Filter  is 
given  in  Figure  4-24.  Program  design  language  is  provided  in 
this  section  for  each  element  of  Figure  4-24  with  the  exception 
of  Find_Polygon_Boundary_Intersections,  Linear_Discriminant_ 
Classifier,  and  Time_To_Violation.  A  description  of  these 
elements  is  provided  in  Appendix  B. 


Fine_Pilter 

Convex_Polygon_Intersection_Check 

FindJPolygon_Boundary_Inter sect ions 
LTnear_Di8criainan7_Clasaifier 
TIae_To_Violation 
Mlxed_Polyg<m__Intersectlon_Check 

Find_Polygon_Boundary_In ter sect ions 
Linear_Di8crimlnant_Cla8sifier 
Ti*e_To_Vioiation 
Group_Into_Intersection_Paira 
Vertical_Violation_Check 
Pind_Exact_Violation_Point8 


FIGURE  4-24 

ELEMENTS  OF  THE  FINE  FILTER 


The  Input  data  required  by  the  Fine  Filter  consists  of: 
•  System  Global  Data  Base 


-  VOLUMES 

The  volume  type  is  obtained — either  "convex”  or 
"mixed."  This  field  is  used  to  determine  which 
polygon  intersection  test  routine  to  use. 

-  VOLUME JJOORMNATES 

The  vertex  points  of  the  polygons  are  obtained  for 
line  Intersection  tests. 


e  Shared  Local  Data  Base 

-  SEGMENTS 

The  trajectory  of  the  aircraft  is  stored  locally  as 
an  ordered  sequence  of  line  segments. 

-  SECOND_ORDER_NOMINEES 

This  table  contains  the  Identity  of  each  polygon 
passing  the  tests  of  the  Second-Order  Coarse  Filter. 


Output 


The  Fine  Filter  produces  a  list  of  environmental  conflicts 
which  are  stored  locally. 

-  ENVIRONMENTAL  JJONFLICTJDATA 

This  table  contains  all  information  necessary  to 
Identify  an  encounter.  This  table  is  input  to 
Encounter  Processing. 

4.3.3  Component  Design  Logic 

The  Fine  Filter  (Figure  4-25)  examines  each  Second-Order  Nomi¬ 
nee  separately  to  determine  if  an  intersection  truly  exists 
with  the  aircraft  trajectory.  To  perform  this  task,  three  steps 
are  taken.  First,  the  extent  of  the  horizontal  penetration  is 
determined.  Second,  the  extent  of  the  vertical  penetration  is 
determined.  And  third,  the  points  of  intersection  are  found. 


[i. 


ROUTINE  Fine  Filter; 

REFER  TO  GLOBAL 
VOLUMES  IN; 

REFER  TO  SHARED  LOCAL 
SEGMENTS  IN 

SECOND_ORDER_NOMINEES  IN; 

DEFINE  TABLES 

SEGMENT_INTERSECTION_POINTS  The  table  of  all  Intersections 
tine"  The  tine  of  the  Intersection 


type 

las  t_cusp_tine 

INTER SECT ION_P AIRS 
start_tine 
stopjtlne 
begln_x 
begin_jr 
begln_z 
begln_t 
end_x 
end_y 
end  z 


Notes  a  boundary  or  Interior  Intersection 
The  tine  of  the  last  cusp  before  the 
intersection 

The  table  of  all  in/out  Intersections 
The  tine  of  the  intersection  going  In 
The  tine  of  the  intersection  going  out 
Start  cusp  of  segnent  on  which  intersection 
occurred 


End  cusp  of  segnent  on  which  Intersection 
occurred 


end_t 

all  AGGREGATE  ( s  tart_t ise , s  t op_t ine , begin_x , beg in_y , beg in_z , 
begln~t,end  x,end_y,end  z,end_t); 

DEFINE  VARIABLES 

PolygonJType  Concave  or  nixed  concave/ convex  polygon 

Vertical_Violatlon  Flag  Indicating  intersection  in  the 

vertical  dlnenslon 

Encounter  Flag  Indicating  that  the  trajectory 

Intersects  the  polygon; 


FIGURE  4-25 
FINE  FILTER 


REPEAT  FOR  EACH  S EC 0ND_0 RDER_N OMI N EE  RECORD; 

SELECT  FIELDS  polygon_type 
FROM  VOLUMES 
INTO  PolygonJType 

WHERE  VOLUMES. volumejld  E£  SECOND  ORDER  NOMINEE . volume_id ; 
REPEAT  FOR  EACH  SEGMENTS  RECORD 
WHERE  SEGMENTS .begin  time  GE 

5ECOND_ORDER_NOMINEE . first_cusp_tiae; 

IF  PolygonJType  E£  "convex" 

THEN 

CALL  Convex  Polygon  IntersectionjCheck 

^SEGMENTS . pair  IN,  SECOND  ORDER_NOMINEES . volume_id  IN 
SEGMENT_INTERSECTION__POINTS  INPUT); 

KT.SE  ** 

CALL  Mixed_Polygon_Interaection_Check 
CSEGMENTS.pair  IN, 

SECOND_ORDER  NOMINEES  .volume_ld  IN, 

SEGMENT_INTER SECTION  _POINTS  INOUTT; 

CALL  Group_Into_Inter8ection  Pairs 

(SEGMENT  INTERSECTION JPOINTS  IN,  INTERSECTIONPAIRS  OUT) 
Encounter  -  "false"; 

REPEAT  FOR  EACH  INTERSECTION  PAIRS  RECORD; 

CALL  Vertical  Violation  Check  (INTERSECTION_PAIRS  INPUT, 
SECOND_ORDER  NOMINEES7volume_id  IN, 

Vert ical_Violation  OUT); 

IF  Vertical  Violation  E<£  "true"; 

THEN 

Encounter  ■  "true"; 

ELSE 

DELETE  FROM  INTERSECTIONJPAIRS 

WHERE  (INTERSECTION  PAIRS. all  EQ 
INTERSECTIONJPAIRS .all) ; 

IF  Encounter  "true"; 

THEN 

CALL  Find_Exact_Violation_Points  (INTERSECTION_PAIRS  IN, 
SECOND_ORDER_NOMINEES. volume  jLd  IN); 

END  Fine_Filter ; 


FIGURE  4-25  (Concluded) 
FINE  FILTER 


The  first  step  deals  with  the  horizontal  extent  only.  Convex 
and  Mixed  polygons  are  treated  differently  In  Con vex_Polygoh_ 
IntersectionjCheck  (Figure  4-26)  and  a  Mi;-ed_Polygon_ 
Inter8ectioa_Check  (Figure  4-27),  respectively;  the  objective 
la  to  check  all  sides  of  the  polygon  for  possible  penetra¬ 
tions.  lb's  Is  done  to  screen  out  polygons  which  are  very 
close  to  the  aircraft's  trajectory  but  do  not  Intersect  It. 
The  detail;i  of  this  step  are  taken  primarily  from  E-MSAW 
documentation  [8,9].  Appendix  C  of  this  document  contains 
updated  details.  The  outcome  of  this  process  is  information 
concerning  the  preliminary  points  of  penetration  (more 
specifically,  the  times  associated  with  these  points)  in  the 
horizontal  extent.  The  number  of  intersection  points  may  be 
one  (for  trajectories  which  begin  or  end  in  the  polygon),  two 
(for  Convex  and  Mixed  polygons) ,  or  more  thap  two  (for  Mixed 
polygons) . 

The  hor*  zontal  points  of  penetration  to  be  considered  are 
selected  by  considering  the  relation  of  the  trajectory  segment 
to  the  polygon.  If  the  trajectory  begins/ends  in  the  polygon, 
then  the  starting/stopping  point  Is  considered  as  one  point  of 
an  Intersection  pair  with  the  Intersection  of  the  polygon  side 
as  the  other.  If  the  trajectory  segment  Intersects  only  two 
sides  of  either  type  polygon,  these  are  used.  If  the  trajec¬ 
tory  Intersects  a  Mixed  polygon  in  several  places,  a  Bet  of 
intersection  pairs  will  be  formed.  Each  pair  will  consist  of 
an  entry  point  and  exit  point  from  the  polygon.  Th  se  penetra¬ 
tion  points  are  grouped  into  "enter-exit"  pairs  in  the  element 
Group_Into_Intersection_Pairs  (Figure  4-28). 

The  second  step  examines  the  vertical  extent  of  penetration  for 
each  Intersection  pair.  This  is  done  in  the  element  Vertical_ 
VlolatlonjCheck  (Figure  4-29).  Figures  4-30  and  4-31  Illus¬ 
trate  this  Btep.  Since  the  polygons  are  defined  by  minimum  and 
maximum  altitudes,  there  can  be  at  most  two  points  of  penetra¬ 
tion  per  segment  in  vertical  extent.  The  process  begins  by 
assuming  the  vertical  points  lie  immediately  over  the  hori¬ 
zontal  points  of  penetration  (hi  and  ho)  and  intersect  the 
aircraft  trajectory  (denoted  by  *x"s).  Then  these  points  are 
compared  with  the  extent  of  the  polygon  in  the  vertical  dimen¬ 
sion.  If  both  vertical  penetration  points  lie  within  this 
range,  the  exact  points  of  Intersection  have  already  been  found 
and  the  polygon  is  added  to  the  list  of  encounters.  If  both  of 
the  vertical  penetration  points  lie  above  the  polygon  or  both 
lie  below,  then  the  trajectory  does  not  intersect  the  polygon, 
the  polygon  is  screened  out  and  rejected. 
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ROUTINE  Convex  Polygon  Intersection  Check; 

PARAMETERS 
SEGMENT  IN, 

Volume  I<T~IN, 

SEGMENT  INTERSECTION  POINTS  INPUT: 

DEFINE  TABLES 

SEGMENT  The  current  trajectory  segment 

xl  The  first  cusp  point  of  the  segment 

yi 

cl 

tl 

x2  The  second  cusp  point  of  the  segment 

y2 

c2 

t2 

begin  AGGREGATE  (xl.yl) 
end  AGGREGATE  (x2,y2) 

SEGMENT_INTERSECTION_POINTS  The  Intersections  with  the  polygon 
time  The  Intersection  time 

type  The  Intersection  location 

"boundary"  of  "interior" 

la8t_cusp_tlme  The  time  of  the  last  cusp  before 

the  Intersection 

ORIENTATIONS  The  orientation  of  the  cusps  (IN  or  OUT) 

begin_orlent  The  orientation  of  the  first  cusp 

beglnjtlme  The  time  of  the  first  cusp 

end_orlent  The  orientation  of  the  end  cusp 

endjtlme  The  time  of  the  end  cusp 

time  The  time  to  violation; 

DEFINE  VARIABLES 
IosumjCounter 
Begln_Orient 
BeginJTlme 
Bad_Orient 
End” Time 


The  IN/OUT  Intersection  counter 
The  orientation  of  the  first  cusp 
The  time  of  the  first  cusp 
The  orientation  of  the  second  cusp 
The  time  of  the  second  cusp; 


FIGURE  4-26 

CONVEX  POLYGON  INTERSECTION  CHECK 


CAT.T.  Find  Polygon  Boundary  Intersections  (SEGMENT  IN,  Voluae  Id 
IN,  ORIENTATIONS  OUT,  SEGMENT  INTER SECTION  JPOINT?  INPUT)}" 
CHOOSE  CASE 

WHEN  Iosum_Counter  Eg,  2  THEN 

INSERT  INTO  SEGMENT_INTERSECTION_POINTS 
(tiae  ■  SEGMENT. tl,  type  ■  "interior", 
lastjcuspjtlae  “  SEGMENT. tl); 

INSERT  INTO  SEGMENT_INTERSECTIONJPOINTS 
(tiae  ■  SEGMENT. t2,  type  ■  "interior", 
last_cusp_t iae  «  SEGMENT. t2); 

WHEN  Iosua  Counter  Eg  -2  THEN 
f  do  nothing  #; 

OTHERWISE 

SELECT  FIELDS  begin  orient,  begln_tlae 
FROM  ORIENTATIONS 
INTO  Begln_Orient,  Begin  Tiae 

WHERE  ORIENTATIONS. tiae  EQ  MIN  (ORIENTATIONS. tiae) 

IF  Begin  Orient  Eg  "In" 

THEN 

INSERT  INTO  SEGMENT_INTERSECTION_POINTS 
(tiae  ■ Begln_Tiae ,  type  “  "Interior", 
last_cu8p_tlae  “  Begin_Tiae); 

SELECT  FIELDS  end  orient,  end  tiae 
FROM  ORIENTATIONS 
INTO  End_Orlent,  EndJTiae 

WHERE  ORIENTATIONS. tiae  Eg  MAX  ( ORIENTATIONS . tine ) 

IF  End  Orient  Eg  "In" 

THEN 

INSERT  INTO  SEGMENT_INTERSECTION_POINTS 
(tiae  -  EndJTiae,  type  -  "interior", 
last_cusp_time  ■  EndJTiae); 

END  Convex_Polygon_Intersection_Check; 


FIGURE  4-26  (Concluded)  . 
CONVEX  POLYGON  INTERSECTIONjCHECK 


ROUTINE  Mixed  Polygon  Intersection_Chedc; 

PARAMETERS 
SEGMENT  IN, 

Vo  line  IT"IN, 

SEGMEOT_INTER SECTION  POINTS  INPUT: 

DEFINE  TABLES 

SIS IffT  The  current  trajectory  segnent 

xl  The  first  cusp  point  of  the  aegaent 

yi 

xl 


tl 

x2  The  second  cusp  point  of  the  segaent 

y2 


x2 

t2 

begin  AGGREGATE  (xl.yl) 
end  AGGREGATE  (x2,y2) 
SEGMENT  INTERSECTIONPOINTS 
tiae“ 
type 

las  t jcuspjtiae 


The  intersections  with  the  polygon 
The  intersection  tine 
The  intersection  location 
"boundary"  of  "interior" 

The  tlae  of  the  last  cusp  before 


ORIENTATIONS 
beglnjorient 
beglnjtlae 
end_ortent 
end  tlae 
tlae 

DEFINE  VARIABLES 


the  intersection 

The  orientation  of  the  cusps  (IN  or  OUT) 
The  orientation  of  the  first  cusp 
The  tlae  of  the  first  cusp 
The  orlentatln  of  the  end  cusp 
The  tlae  of  the  end  cusp 
The  tlae  to  violation; 


Iosuajbouster 
Begin  Orient 
BeglnTlae 
Bad  Orient 
EndJTlne 


The  IN/OUT  intersection  counter 
The  orientation  of  the  first  cusp 
The  tine  of  the  first  cusp 
The  orientation  of  the  second  cusp 
The  tine  of  the  second  cusp; 


FIGURE  4-27 

MIXED  POLYGON  INTERSECTION  CHECK 


4 

a 


CALL  Find  Polygon_Boundary  Intersections  (SEGMENT  IN,  Volume_Id 
IN,  ORIENTATIONS  OUT,  SEGMENT_INTERSECTION_POINTS  INPUT); 
CHOOSE  CASE 

WHEN  Iosun  Counter  EQ  2  THEN 

insert  Into  segment jJTIEsectign_pqints 

(tine  -  SEGMENT,  tl,  type  -  "interior", 
lastjcuspjtine  “  SEGMENT. tl); 

WHEN  IosuajCounter  E<£  -2  THEN 
I  do  nothing  #; 

OTHERWISE 

SELECT  FIELDS  begin  orient,  begin  tine 
FROM  ORIENTATIONS 
INTO  Begin_Orient ,  BeginJTiae 

WHERE  ORIENTATIONS. tiae  E£  MIN  (ORIENTATIONS. tine); 

IF  Begln_Orlent  E£  "in" 

THEN  ~ 

INSERT  INTO  SEGMENT_INTERSECTION_POINTS 
(time  »  BeginJTiae,  type  •  "interior", 
last_cusp_tlae  ■  Begin_Tine); 

SELECT  FIELDS  end_orlent,  end”  time 
FROM  ORIENTATIONS 
INTO  End_Orient,  End  Tlae 

WHERE  ORIENTATIONS,  tlae  E£  MAX  (ORIENTATIONS. tine); 

IF  End_Orient  BJ  "in" 

THEN 

INSERT  INTO  SEGMENT_INTERSECTION_POINTS 
(tlae  "  EndJTiae,  type  ■  "interior", 
lest_cusp_tiae  ■  End  Tiae); 

END  Mixed_Polygon_Intersection_ChecJc; 


FIGURE  4-27  (Concluded) 
MIXED  POLYGON  INTERSECTION  CHECK 
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ROUTINE  Group_Into_Inter8ection_PairB ; 

PARAMRTRRS  ~ 

SK5REST  INTERSECTION  POINTS  IN, 

INTERSECTION  PAIRS  OUT; 

REFER  TO  SHARED" LOCAL 
SEGMENTS  IN; 

DEFINE  TABLES 

SEGMENT_INTERSECTION_POINTS  The  Intersection  points 
tine  ~  The  Intersection  tine 


type 

The  location  of  the  Intersection 

(boundary  or  Interior) 

lastjcuspjtlne 

The  tine  associated  with  the  last 

cusp  before  the  Intersection 

INTER SECTION_PAIRS 

The  Intersections  grouped  Into  the 

enter  and  ezlt  violation  points 

startjtlne 

The  tine  associated  with  the 

Intersection  entering  the  polygon 

stopjtlne 

The  tine  associated  with  the 

intersection  exiting  the  polygon 

•  begln_z 

The  segnent  on  which  the  intersection 

lies 

beglnjr 

(the  first  cusp) 

beglnjs 

begin_t 

endjz 

(the  second  cusp) 

end_y 

end_r 

'  end  t 

segnent  AGGREGATE  (begin_z,begin_y,begin_r,begin_t , 

end  z7endjr(end  *,end_t); 

DEFINE  VARIABLES 

Point  The  flog  Indicating  the  first  or  last 

point  of  a  segnent 

S tart  Tine  The  tine  of  the  first  cusp  of  a  segnent; 


FIGURE  4-28 

GROUP  INTO  INTERSECTION  PAIRS 


DELETE  FROM  SEGMENT_INTER SECTION  POINTS 

WHERE  NOT  (  SEGMENT_INTERSECTION_POINTS . time  EQ 
min~Tsegment  INTERSECTION  POINTS. tine)  OR 
SEGMENTJtNTERSECTIONPOINTS . type  EQ  "boundary"  OR 
SEGMSNT  INTERSECTION  POINTS. TIME  EQ  ~ 

MAX  ( SBSkENT_INTERSEStlON_POINTS .tine)  ); 

Point  ““start"; 

REPEAT  POR  EACH  SEGMENTINTERSECTION  JOINTS  RECORD 
IP  Point  EO  "start" 

ms 

Start  Tine  -  SEGMENT_INTERSECTION_POINTS . time ; 

SEGMENT  -  SELECT  FIELDS  ALL 
PROM  SEGMENTS 

WHERE  (SEGMENTS . begin_t  EQ  StartJFime); 

INSERT  INTO  INTERSECT ION_PAIRS  (start  tine  - 

SEGMENT_INTERSECTION_POXNTS . tine ,  segment  -  SEGMENT); 
Point  -  “stop"; 

PJfRP 

UPDATE  IN  INTER SECTION_PAIRS  (stop  tine  - 
SEGMENT  INTERSECTION  POINTS. tine) 

WHERE  INTERSECTION_PAIRS .  s  tart_t  lne  EQ  StartJTlne; 
Point  ■  "start"; 

END  Group_Into_Intersectlon_Palrs; 


FIGURE  4-28  (Concluded) 
GROUP_INTO_INTERSECTION_PAIRS 
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ROUTINE  Vertical  Violatlon_Check; 

PARAMETERS 

INTER SECTION_DATA  INPUT. 

Volumeld  IN 
Vertlcal_Vlolation  OUT; 

REFER  TO  GLOBAL 
VOLUMES  IN; 

DEFINE  TABLES 

lNTlRSECTION_DAIA  The  Intersections  grouped  into  the 

enter  and  exit  violation  points 


atartjtlae 

stopjtime 

begin_x 


The  tine  associated  with  the 

intersection  entering  the  polygon 
The  tine  associated  with  the 

intersection  exiting  the  polygon 
The  segment  on  which  the  intersection 
lies 


begin_y  (the  first  cusp) 

beglnjE 

begin_t 

end_x  (the  second  cusp) 

end_y 

end_r 

end_t; 

DEFINE  VARIABLES 


Voluae_Id 

Vertical_Violation 

Floor 

Celling 
Start_Tiae 
StopJUme 
BeglnJT 
Begin  Z 
Bad  T 
End”  Z 
Z  Vel 
Tl 
T2 
Z1 
22; 


The  volume  identifier 
The  flag  indicating  that  a  violation  in 
the  vertical  dimension  has  occurred 
The  minimum  vertical  extent  of  the  polygon 
The  maximum  vertical  extent  of  the  polygon 
The  time  of  entrance  violation 
The  time  of  exit  violation 
The  first  cusp  time 
The  first  cusp  altitude 
The  second  cusp  time 
The  second  cusp  altitude 
Average  vertical  velocity  on  the  segment 
Intermediate  variables 


FIGURE  4-29 

VERTICAL  VIOLATION  CHECK 


SELECT  FIELDS  floor  altitude .celling  altitude 
FROM  VOLUMES 
INTO  Floor, Celling 

WHERE  VOLUMES  .voluae__ld  E£  Voluae_Id; 

SELECT  FIELDS  start  tiae,atop_tlae, begin  z, begin  t,end_z,end_t 
FROM  INTERSECT  IGN_DATA 

INTO  StartJTiae , Stop_Tl«e , Begln_Z , Begin_T , End_Z , End_T ; 

Z_Vel  ■  (Begln_Z  -  End_Z)  /  (End_T~ -  BeginJT); 

Tl  *  Start_Tl«e  -  BeginJT ; 

T2  •  Stop  Tine  -  End  T; 

Z1  -  Z  VeT  *  Tl  +  Begln  Zj 
Z2  -  Z_Vel  *  T2  +  Begln_Z; 

IF  (Z1GT  Celling  AND  Z2  GT  Celling)  OR 
(Z1  LT  Floor  AND  Z2  LT  Floor) 

THEN 

Vertlcal_Vlolatlon  ■  “false"; 

ELSE 

IF  Z1  GT  Cell lng 
THEN 

Start JTine  -  Tl  +  (Celling  -  Zl)/Z  Vel; 

IF  Z1  LT  Floor 
THEN 

StartJTine  -  Tl  +  (Floor  -  Zl)/Z_Vel; 

IF  Z2  GT  Celling 
THEN 

StopJTlae  ■  T2  +  (Ceiling  -  Z2)/Z  Vel; 

IF  Z2  LT  Floor 
THEN 

StopJTlae  *  T2  +  (Floor  -  Z2)/Z  Vel; 

UPDATE  IN  INTER SECTION_DATA 

(start_time  »  StartJTlne,  stoptime  -  StopJTine); 
Vertlcal_Vlolatlon  ■  "true"; 

END  Vertical_Violation_Check; 


FIGURE  4-29  (Concluded) 
VERTICAL  VIOLATION  CHECK 


(a)  Exact  intersection  Found 


(b)  No  Intersection  Found 


FIGURE  4-30 

VERTICAL  PENETRATION  CHECK 
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If  neither  of  the  above  cases  hold,  then  the  process  must 
determine  the  true  points  of  Intersection.  This  Is  done  In 
Find_Exact_Violation_Polnts  (Figure  4-32)  by  first  computing 
the  difference  between  the  assumed  penetration  altitude 
(denoted  by  "a^"s  in  Figure  4-31)  and  the  altitude  boundary 
of  the  polygon.  From  the  aircraft's  verti  :al  velocity 
(approximated  by  consideration  of  segment  data)  and  the  above 
difference  in  altitude,  a  new  time  of  intersection  is  computed. 

After  the  intersection  times  have  been  found,  the  true  four¬ 
dimensional  extent  of  penetration  is  determined  by  projecting 
in  x,y  and  z  using  their  respective  derived  velocities.  For 
the  mixed  polygon  case  with  multiple  intersection  points,  only 
the  first-in  and  last-out  points  of  penetration  will  be 
recorded.  The  case  is  illustrated  in  Figure  4-33. 

4.4  Encounter  Processing 

4.4.1  Mission 


The  Fine  Filter  has  determined  that  an  encounter  is  present  for 
the  given  aircraft  trajectory  segment.  Encounter  Processing 
records  the  relevant  information  about  the  encounter  in  the 
global  data  base.  The  list  of  Encounters  is  used  elsewhere  in 
the  system  for  the  display  of  conflict  information. 

4.4.2  Design  Considerations  and  Component  Environment 

Dlls  component  exists  to  copy  information  from  the  local  data 
base  into  the  global  data  base. 

Input 

The  input  data  required  by  Encounter  Processing  consists  of: 

•  System  Global  Data  Base 
-  CURRENTJIIME 

The  current  system  time  is  stored  in  this  table. 


ROUTINE  Find_Exact_Violation_Points; 

PARAMETERS 

INTERSECTIONJPOINTS  IN, 

Voluaeld  IN; 

REFER  TO  SHARED  LOCAL 

ENVIRONMENTAL  CONFLICTJJATA  OUT; 

DEFINE  TABLES  “ 

INTERSECTIONJPOINTS  The  intersections  grouped  into  the 

enter  and  exit  violation  points 


startjtlae 

The  tlae  associated  with  the 

intersection  entering  the  polygon 

stopjtlae 

The  tiae  associated  with  the 

intersection  exiting  the  polygon 

beginjc 

The  segaent  on  which  the  intersection 

lies 

begin  y 

(the  first  cusp) 

begin_z 
begin  t 

end  x 

(the  second  cusp) 

end_jr 
endz 
end  t; 

DEFINE  VARIABLES 

Voluae_Id 

The 

voluae  identifier 

StartJTiae 

The 

tiae  of  entrance  violation 

StopJTiae 

The 

tiae  of  exit  violation 

Begin  T 

The 

first  cusp  tiae 

Begin  X 

The 

first  cusp  X 

Begin  Y 

The 

first  cusp  Y 

Begin-  Z 

The 

first  cusp  altitude 

End  T~ 

The 

second  cusp  tiae 

End  X 

The 

second  cusp  X 

find  Y 

The 

second  cusp  Y 

End_Z 

The 

second  cusp  altitude 

First_In 

The 

intersection  point  when  the  trajectory 

first  enters  the  polygon 

Last_Out 

The 

intersection  point  when  the  trajectory 

last  exits  the  polygon 

Avg  X  Vel 

The  average  velocity  in  X  over  the  segaent 

Avg  Y~ Vel 

The 

average  velocity  in  Y  over  the  segaent 

Avg_Z  Vel 

The  average  velocity  in  Z  over  the  segaent 

FIGURE  4-32 

FIND  EXACT  VIOLATION  POINTS 


SELECT  FIELDS  start_time 
FROM  INTER  SECT ION J*  OINTS 
INTO  First_In 

WHERE  INTERSECTION_POINTS.start_time  EQ 
MIN  (INTERSECTION_POINTS.start_time); 

SELECT  FIF-T.ns  stop_time 
FROM  INTERSECT ION_P OINTS 
INTO  Laat_Out 

WHgffi  INTER SECTION_POINTS .  8  top_t  ime  EQ 
MAX  (INTERSECTION J>  OINTS .  8top_time  ) ; 

SELECT  FIELDS  begin_x ,begin_y , begin_z , begin_t , 
end_x , end_y , endjz ,  end  t 
FROM  INTER SECTION_POINTS 

INTO  BeginJT, BeginJT, Begin  Z, Begin  T,End  X , End_Y , End_Z , End  T 
WHERE  INTERSECTION JP  OINTS .star t_time  E£  First  Time; 

Avg_X_Vel  -  (End_X  -  Begin  X)  /  (tod  T  -  BeginjrJ; 

Avg_Y_Vei  -  (todjr  -  BeginJT)  /  (EndJT  -  BeginJT); 

Avg_Z_Vel  "  (End~Z  -  Begin  Z)  /  (EndJT  -  BeginJT); 

X  ■  Begin_X  +  Avg_X_Vel  *  TStartJT  -“BeginJT); 

Y  -  BeginJT  +  AvgYVel  *  (Start  T  -  Begin“T); 

Z  -  Begin- Z  +  Avg  Z  Vel  *  (Start-!  -  BeginJT); 

INSERT  INTO  ENV IRTMIfeNT AL_C ONFLI^T  JDATA 

(time  “  StartJTime,  x  ■  X,  y  "  Y,  altitude  ■  Z, 
volumejid  ■  Voluoe_Id); 

SELECT  FIELDS  begin_x  ,begin_y ,begin_z  ,begin_t , 
end_x , end_y , end_r , end_t 
FROM  INTER SECTION_POINTS 

INTO  BeginJT, Begin  Y,Begin_Z,BeginJT,End  X,  End JT,End_Z,  EndJT 
WHERE  INTERSECT ION JP OINTS .stop  time  E&  Stop  Time; 

Avg  JT  Vel  -  (tod_X  -  Begin_X)  /  (todJT  -  Begin_T); 

AvgjrVei  -  (EndJT  -  BeginJT)  /  (EndJT  -  BeginJT); 

Avg- Z— Vel  "  (End  Z  -  Begin- Z)  /  (End  T  -  BeginJT); 

X  -  BeginJT  +  Avg  X  Vel  *  Tstop  T  -  Begin  T); 

Y  -  BeginJT  +  Avg- Y— Vel  *  (Stop-!  -  BeginJT); 

Z  -  Begin  Z  +  Avg  Z  Vel  *  (Stop  T  -  Begin  T); 

INSERT  INTO  ENV IRONMENTALjC ONFLICT  JJAIA 

(time  "  StopJTime,  x  ■  X,  y  ■  Y,  altitude  “  Z, 
volumejLd  -  Volume_Id) ; 

END  Find  Exact  Violation_Points; 


FIGURE  4-32  (Concluded) 
FIND  EXACT  VIOLATION  POINTS 
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•  Shared  Local  Data  Base 


ENV IRONMENTAL_CONFLICT_DATA 

Information  stored  locally  which  Includes  the  enter 
and  exit  positions  of  the  trajectory  with  respect  to 
each  penetration.  Altitudes  and  times  are  also 
given. 


Output 

Encounter  Processing  updates  the  global  data  base  to  include: 

•  System  Global  Data  Base 
-  ENV IR OfWE NTAL_C ONFLI CTS 

Encounter  information  is  stored  for  access  by  other 
system  functions. 

4.4.3  Component  Design  Logic 

Encounter  Processing  (Figure  4-34)  is  essentially  a  "house¬ 
keeping"  function  used  to  record  the  encounters  found  for  a 
given  aircraft.  The  data  recorded  in  the  table  ENVIRONMENTAL 
CONFLICT_DATA  by  the  Fine  Filter  is  used.  The  time  that  the 
system  should  display  this  predicted  penetration  to  the 
cognizant  controller  is  given  as  "now." 
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ROUTINE  Encounter_ProcesBing; 

PARAMETERS  ™~ 

toe  Fl_Id;  The  local  Flight  Identifier 

REFER  TO  SHARED  LOCAL 

ONMENTAL  CONFLICT  DATA  IN; 

REFER  TO  GLOBAL 
CURRENTTME  IN, 

ENVIRONMENT A.I  CONFLICTS  OPT; 

DECLARE  VARIABLES 

Loc  FI  Id  The  local  Flight  Identifier; 

## 

REPEAT  FOR  EACH  ENV IR ONNENTALjCONFLICT  DATA  RECORD; 
INSERT  INTO  ENVIRONMENTAL  CCNFLICT  ” 

(flJLd  -  Loc_Fl_Id , 

tine  -  ENVIRC#iffiNTAL_CONFLICT_DATA. tine , 

z  -  ENVmONMENTALjCONFLICT  DATA.*, 

y  -  ENVIRONMENTAL_CONFLICT_DATA. y, 

altitude  -  ENV IRONMENTAL_C CNFLI CT_DAT A .altitude, 

voluae_ld  -  ENV IR CNMENTAL_C ONFLI  CT_DATA . volune_i d , 

diaplay_as_advlsory_tiac  ■  CURRENT JEIME. tine); 

END  Encounter_Proces8ing ; 


FIGURE  4-34 
ENCOUNTER  PROCESSING 


fit* 


APPENDIX  A 


AIRSPACE  PROBE  DATA  TYPES 


FL  CUSPS 


cusp  AGGREGATE  (time,x,y,z) 


This  table  contains  the  cusps  associated  with  the  trajectory 
being  examined. 

TIME  The  tine  associated  with  the  cusp  point 

x  The  x  coordinate  of  the  cusp  point 

y  The  y  coordinate  of  the  cusp  point 

z  The  z  coordinate  of  the  cusp  point 


SEGMENTS 


I  BEGIN_TIME  I  begln_x  I  begin_y  I  begin_z 


I  end_t  lne  I  end_x  |  end_y  I  end_z 


begin  AGGREGATE  (begln_tlme,begln_x, begin  y,begln_z) 
end  AGGREGATE  (end_tlme,end  x , en , end_zT 
pair  AGGREGATE  (begln_tlne,Fegln_x,begln_y,begin_z,end_tlme, 
end_x ,  end_y ,  endjz  ) 


This  table  contains  the  trajectory  segments  associated  with 
the  current  trajectory  being  examined. 


BEGIN_TIME  The  tine  associated  with  the  cusp  at  the  beginning 
of  the  segaent. 

begln_x  The  x  coordinate  associated  with  the  cusp  at  the 
beginning  of  the  segment. 

begin_y  The  y  coordinate  associated  with  the  cusp  at  the 
beginning  of  the  segment. 

begln_z  The  z  coordinate  associated  with  the  cusp  at  the 
beginning  of  the  segaent. 

end_tiae  The  time  associated  with  the  cusp  at  the  end  of 
the  segaent. 

end_x  The  x  coordinate  associated  with  the  cusp  at  the 

end  of  the  segaent. 

end_y  The  y  coordinate  associated  with  the  cusp  at  the 

~  end  of  the  segaent. 

end_z  The  z  coordinate  associated  with  the  cusp  at  the 

end  of  the  segment. 


FIRST_ORDER_NOMINE  ES 

^ - - - - - h 

I  VOLUME  ID  I  first_cusp__time  | 

- - - - - - - H 

all  AGGREGATE  (volume  id, first  cusp  tine) 


This  table  contains  the  voluaes  which  have  passed  the  First 
Order  Coarse  Filter. 

VOLUME_ID  Identifier  of  a  volume. 

fir8t_cusp_time  The  time  associated  with  the  cusp  known 
“  *”  to  be  close  to  the  voluae. 


SECOND  _ORDER_NOMINEES 

•f  •■■■  - - - —  - -  I 

I  VOLUME_ID  |  first_cusp_time  I 

H - — - — - — - h 

all  AGGREGATE  (volumejLd.first  cusp  tine) 


This  table  contains  the  volumes  which  have  passed  the  Second 
Order  Coarse  Filter. 

VQLIJME_ID  Identifier  of  a  volume. 

firs t_cusp_time  The  time  associated  with  the  cusp  known 

to  be  close  to  the  volume. 


ENVIRONMENTAL_CONFLICT_DATA 

♦ -  - — . — . -■ . . . 1- 

I  VOLUME_ID  |  TINE  I  z  |  y  |  altitude  I 
+ - - - ¥ 


This  table  contains  information  on  environmental  conflicts 
for  the  current  trajectory  being  ezamlned. 


VOLUME_ID  The  Identifier  of  the  volume  with  which  the 
environmental  conflict  occurred 

TIME  The  time  associated  with  the  environmental 

conflict 


z 


The  z  coordinate  associated  with  the  environmental 
conflict 


y 


The  y  coordinate  associated  with  the  environmental 
conflict 


altitude  The  z  coordinate  associated  with  the  environmental 
conflict 
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APPENDIX  B 


AIRSPACE  PROBE  ALGORITHMS 


This  Appendix  presents  the  detailed  Airspace  Probe  elements  refer¬ 
red  to  by  the  four  Airspace  Probe  components.  Those  elements  used 
for  the  determination  of  horizontal  penetrations  are  found  in 
Appendix  C.  Those  elements  are  segregated  to  emphasize  the  close 
correlation  with  Appendix  C  of  Reference  8.  All  other  elements  are 
listed  below. 

Intersection  checks  are  performed  using  a  linear  discriminant.  The 
discriminant  is  used  to  discriminate  between  points  cm  the  left 
side  of  a  line  and  the  points  on  the  right  (we  nay  Interpret  the 
line  as  having  a  direction).  This  technique  may  be  used  to  find 
which  side  of  a  trajectory  segment  the  points  of  the  rectangle 
lie.  If  all  points  lie  only  to  one  side,  the  segment  does  not 
Intersect  the  rectangle.  If  points  lie  on  both  the  left  and  right 
side,  an  intersection  must  occur  (see  Figure  B-l) . 

B.l  Grid 


This  routine  is  responsible  for  accepting  an  input  (x,y)  position 
and  finding  the  grid  cell  that  the  point  is  in.  The  Cell  Id  of  the 
grid  cell  is  returned. 


ROUTINE  Grid; 

PARAMETERS 

— V  In, 

7  IN, 

Box  OUT; 

REFER  TO  GLOBAL 

ENVIRONMENTAL  CELL  DIMENSIONS; 

DEFINE  VARIABLES'" 

The  X  coordinate 
The  7  coordinate 


X, 

7. 

Box; 


of 

of 


the 

the 


point 

point 


The  cell  which  the  point  (X,7)  is  in 


B-l 


u 


FIGURE  B-1 

DETERMINATION  OF  ORIENTATION  OF  A  POINT  TO  A  LINE 


## 


SELECT  FIELDS  cell_id 

FROM  ENVIRONMENTAL  CELL  DIMENSIONS 
INTg  Box 

WHERE  ENVIRONMENTAL_CELL_DIMENSIONS.aln  x  LE  X  AND 
ENVIRONMENTAL_CELL_DIMENS IONS .max- x  GT  X  AND 
ENVIRONMENTAL  CELLJJIMENSIONS.miny  LE  Y  AND 
ENVIRONMENTAL- CELL  DIMENSIONS .max~y  GT  Y; 

END  Grid; 


B.2  Linear  Discriminant  Classifier 


This  routine  uses  the  coordinates  of  the  endpoints  of  a  line  segment 
and  the  coordinates  of  a  third  point  to  determine  which  side  of  the 
line  segment  (left  or  right  as  measured  from  the  first  point  to  the 
second  point)  the  third  point  is  on.  The  method  involves  the 
determinant  of  a  two-dimensional  matrix  whose  elements  are  composed 
of  the  differences  between  the  line  points  and  the  third  point. 


ROUTINE  Llnear_Di8criainant_Classifier; 


PARAMETERS 


U1  IN, 

U2  IN, 

VI  IN, 

V2  IN, 

Up  IN, 

Vp  IN, 

Side  OUT; 

DEFINE  VARIABLES 


## 


U1 

U2 

VI 

V2 

Up 

Vp 

Side 

Discriminant 


The 

The 

The 

The 

The 

The 

The 

The 


Discriminant  “  (U2 
IF  Discriminant  GT 
THEN 

Side  -  "left" 
ELSE 

Side  -  "right"; 


coordinate  of  the  first  point  on  the  line 
coordinate  of  the  second  point  on  the  line 
coordinate  of  the  first  point  on  the  line 
coordinate  of  ’■he  second  point  on  the  line 
U  coordinate  of  the  point  to  be  classified 
V  coordinate  of  the  point  to  be  classified 
side  of  the  line  on  which  the  point  "p"  lies 
value  of  the  discriminant 


-  Ul)  *  (Vp  -  VI)  -  (Up  -  Ul)  *  (V2  -  VI); 
0 


END  Linear  Discriminant  Classifier; 
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B.3  Find  Polygon  Bounda 


This  routine  will  accept  a  line  segment  and  a  set  of  vertices  repre¬ 
senting  a  polygon  and  determine  the  horizontal  intersection  points 
(if  there  are  any).  The  returned  information  is  a  table  containing 
the  intersection  points  of  the  segment  with  the  polygon. 


ROUTINE  Find_Polygon_Boundary  Intersections; 

PARAMETERS 
SEGMENT  IN, 

Volume  lT~ IN, 

ORIENTATIONS  OUT, 

SEGMENT_INTERSECTION  POINTS  INPUT; 

REFER  TO  GLOBAL 

VaLUME_COORDINATES  IN; 

DEFINE  TABLES 

SEGMENT  The  current  trajectory  segment 

*1  The  first  cusp  point  of  the  segment 

yl 
zl 
tl 

x2  The  second  cusp  point  o: 

y2 
z2 
t2 

begin  AGGREGATE  (xl,yl) 
end  AGGREGATE  (x2,y2) 

SEGMENT_INTERSECTION_POINTS  The  Intersei 

time  The  intersei 

type  The  intersei 


The  second  cusp  point  of  the  segment 


las  t_cusp_time 

ORIENTATIONS 

begin_orient 

beginjtime 

end_o7ient 

end_time 

time 


POINTS  The  Intersections  with  the  polygon 
The  intersection  time 
The  intersection  location 
"boundary"  of  "interior" 

The  time  of  the  last  cusp  before 
the  intersection 

The  orientation  of  the  cusps  (IN  or  OUT) 

The  orientation  of  the  first  cusp 
The  time  of  the  first  cusp 
The  orientation  of  the  end  cusp 
The  time  of  the  end  cusp 
The  time  to  violation 


\>VXv' 


PQLYGON_VERTICES  The  vertices  of  the  polygon 

x  The  x  coordinate  of  the  vertex 

y  The  y  coordinate  of  the  vertex 

vertex_nuaber  The  sequence  nuaber  of  the  vertex 
PV  The  previous  vertex  point 

x  The  x  coordinate  of  the  vertex 

y  The  y  coordinate  of  the  vertex 

CV  The  current  vertex  point 

x  The  x  coordinate  of  the  vertex 

y  The  y  coordinate  of  the  vertex 

DEFINE  VARIABLES 

Voluae_l3  The  voluae  Identifier 

C_Side  The  orientation  of  the  current  vertex 

P_Side  The  orientation  of  the  previous  vertex 

Begin_Side  The  orientation  of  the  first  cusp  point 

End_Side  The  orientation  of  the  second  cusp  point 

Order  The  sequence  nuaber  of  the  current  vertex 

VlolatlonJFiae  The  tine  to  violation 

Int_Count_  The  nuaber  of  Intersections  thus  far 

Iosua  Counter;  The  nuaber  of  IN/OUT  intersections 

##  " 

POLYGONVERTICES  -  SELECT  FIELDS  x,y ,vertex_nuaber 
FROM  VOLUMEjOOORDINATES 

WHERE  VOLOME_CO ORDINATES .voluae  id  Eg  Voluaeld; 

PV  -  SELECT  FIELDS  x,y 
FROM  POLYGON  VERTICES 

WHERE  POLYGON_VERTICES  .vertexjnuaber  Eg  1; 

Order  “  2; 

IntjCount  “  0; 

Io8ua_Counter  ■  0; 

CALL  LI near_Dl a cr 1 mlnan t  Classifier  (S. begin  IN,  S.end  IN, 

PV  IN,  P_Side  OUT); 

REPEATTOR  EACH  POLYGON_VERTICES  RECORD; 

WHERE  POLYGON  VERTICES. vertex  nuaber  NE  1  AND  Int  Count  LT  2 
CV"  SELECT  FIELDS  x,y 
FROM  POLY GON_VERT ICES 

WHERE  POLGON~VERTICES. vertexjnuaber  Eg  Order; 

CALL  Linear  Discrlalnant  Classifier  (S. begin  Df, 

S.end  INT  CV  IN,  C_Sl.de  OUT); 


vertex  nuaber 


The  voluae  Identifier 

The  orientation  of  the  current  vertex 

The  orientation  of  the  previous  vertex 

The  orientation  of  the  first  cusp  point 

The  orientation  of  the  second  cusp  point 

The  sequence  nuaber  of  the  current  vertex 

The  tlae  to  violation 

The  nuaber  of  Intersections  thus  far 

The  nuaber  of  IN/OUT  Intersections 
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IF  C  Side  NE  P  Side 
THEN"  “ 

CALL  Linear  Discriminant  Classifier  (PV  IN,  CV  J  N, 

S. begin  IN,  Begin  Side  OUT); 

CALL  Linear  Discriminant  Classifier  (PV  IN,  CV  IN, 

S.end  IN7  End_Side  OUT); 

CHOOSE  CASE 

WHEN  Begin_Side  Eg  "in"  AND  End__Side  Eg  "in"  THEN 
IosumjCounter  ■  Iosum  Counter  +  1; 

WHEN  Begin_Side  Eg  "out"~AND  End_Side  Eg  "out"  THEN 
Iosum  Counter  ■  Iosum  Counter  -  1; 

OTHERWISE 

CALL  Time_To_Violation  (PV  IN,  CV  IN,  S. begin  IN, 
S.end  IN,  Violation  Time  OUT); 

INSERT  INTO  SEGMENT_INTERSECTION_POINTS 

(time  ■  ViolationJTime,  type  **  "boundary", 
last  cusp_time  “  S^. begin  t); 

INSERT  INTO  ORIENTATIONS  ~ 

(begin__orient  ■  BeginJSide,  begin_time  “  S.begin_t, 
end_orient  ”  EndSide,  endjtlme  "  S.endjt, 
time  ■  Violation_Time) ; 

Int_Count  ■  Int_Count  +  1; 

LAST  VERTEX  -  SELECT  HELPS  ALL 

FROM  THIS__VERTEX; 

Order  "  Ordeir  +  1; 

END  Find_Polygon_Boundary_Intersections ; 


B.4  Time  To  Violation 

This  routine  determines  the  time  on  a  given  trajectory  segment  that 
a  violation  occurs. 


ROUTINE  Time_To  Violation; 
PARAMETERS 


Nix  IN, 
Nly  IN, 
N2x  IN, 
N2y  IN, 
Cx  IN, 
Cy  IN, 
Ct  IN, 
Px  IN, 

Py  Jn. 
Pt  In, 

TV  OUT: 


DEFINE  TABLES 

VN  The  vector  froa  points  N1  to  N2 

x 

y 

VC  The  vector  froa  points  N1  to  C 

x 

y 

VP  The  vector  froa  points  C  to  P 

x 


y 

DEFINE  VARIABLES 


Mix 

The 

X 

value 

of 

the 

point 

N1 

Nly 

The 

y 

value 

of 

the 

point 

N1 

N2x 

The 

X 

value 

of 

the 

point 

N2 

N2y 

The 

y 

value 

of 

the 

point 

N2 

Cx 

The 

X 

value 

of 

the 

point 

C 

cy 

The 

y 

value 

of 

the 

point 

C 

ct 

The 

t 

value 

of 

the 

point 

c 

Px 

The 

X 

value 

of 

the 

point 

p 

py 

The 

y 

value 

of 

the 

point 

p 

pt 

The 

t 

value 

of 

the 

point 

p 

Tp  The  tlae  froa  point  C  to  P 

NXC  The  cross  product  of  N  with  C 

NXP  The  cross  product  of  N  with  C 

Tv;  The  tlae  to  the  violation 

## 

VN.x  -  N2x  -  Nix; 

VN.y  -  N2y  -  Nly; 

VC.x  -  Cx  -  Nix; 

VC.y  -  Cy  -  Nly; 

VP.x  ■  Px  -  Cx; 

VP.y  -  Py  -  Cy; 

Tp  ■  Pt  -  Ct; 

NXC  -  CROSS (VN, VC); 

NXP  -  CROSS(VN.VP); 

Tv  -  (NXP  *  Tp)/(NXC  +  NXP); 

END  Tlae  To  Violation: 


APPENDIX  C 


POLYGON  HORIZONT  L  VIOLATION  DETERMINATION 


This  Appendix  was  taken  mainly  froa  the  NAS  E-MSAW  Computer  Program 
Functional  Specification  (CPFS)  [9]  and  is  segregated  from  the  rest 
of  the  Airspace  .“robe  Specification  to  emphasize  that  fact.  The 
algorithms  have  been  modified  to  account  for  the  strategic  nature  of 
the  trajectory /polygon  conflicts. 

An  aircraft  trajectory  Is  determined  to  be  In  penetration  with  a 
polygon  If  any  portion  of  any  trajectory  segment  penetrates  the 
adapted  volume  of  airspace. 

Due  to  the  Increased  complexity  of  possible  shapes  when  polygon 
sides  are  adapted  such  that  concave  angles  are  formed*  the  following 
procedure  will  be  divided  into  two  separate  algorithms  to  facilitate 
the  handling  of  the  simpler  (and  possibly  more  frequent)  geome¬ 
tries.  The  individual  configurations  considered  by  each  algorithm 
are  as  follows: 

•  Algorithm  1  will  operate  on  polygons  that  contain  only 
convex  angles. 

e  Algorithm  2  will  op<  rate  on  polygons  with  a  mixture  of 
concave  and  convex  an* les. 

An  Indication  of  which  algorithm  is  applicable  to  which  polygons  is 
derived  by  Polygon  Adaptation. 

C.l  Known  Quantities  and  Relationships 

The  trajectory  segment  will  be  defined  by  the  following  quantities: 

•  Initial  cusp:  ■  (x,y,z,t)i 

e  Next  cusp:  Ci+i  ■  (x,y,z,t)i+i 

The  polygon  is  defined  by  the  following  adaptation  derived  data: 

•  Algorithm:  Indication  of  which  algorithm  applies  to  this 

polygon 

e  Altitudes:  Minimum  and  Maximum 

e  Total  Lines:  N  (the  total  number  of  polygon  line  segments) 

•  Vertices:  (Xx  .Yj^) ,  (X2  ,Y2)  .  .  .  (XN,YN) 


The  polygon  vertices  which  make  up  the  N  line  segments  are  defined 
in  a  clockwise  direction.  This  consistent  ordering  is  necessary 
since  the  algorithms  assume  that  the  polygon  lies  to  the  right  of 
line  segments  defined  by  the  vertices.  Counterclockwise  ordering 
(only)  may  be  used  with  the  proper  changes  in  the  algorithms. 

C.2  Linear  Discriminant  Classifier 

A  concept  essential  to  the  understanding  of  the  algorithms,  and  a 
computation  used  frequently  by  them,  is  the  orientation  of  a  point 
to  a  line.  The  orientation  will  be  determined  by  considering  an 
infinite  line  defined  by__  the  points  ■  (Ui,V^)  and  N2  * 

(Uj,  Vj)  and  a  vector  N,  defined  from  point  to  N2  as 

follows: 


N  -  (U2-U1,V2-V1) 

Consider  also  a  vector  P,  from  point  %  to  point  p  *  (Up,  Vp) 
as  (see  Figure  C-l): 

?  -  (Up-Ui.Vp-Vi) 

An  expression  for  sin  6  can  be  obtained  by  taking  the  cross  product 
from  If  to  P: 


N  x  P  -  I N I  iPl  sin  6  -  (U2-U1)(Vp-V1)-(Up-U1)(V2-V1)  [C-l] 


Since  the  magnitudes  of  vectors  N  and  P  are  always  nonnegative,  the 
sign  of  sin  6  is  positive  if: 


(U2-U1)(Vp-V1)  -  (Op-upo^-Vi)  >  0.* 


Mote  that  if  the  above  expression  is  true,  the  point  p  is  confined 
to  the  area  to  the  left  of  the  line  (as  shown  in  Figure  C-l)  or  is 
on  the  line.  This  situation  will  define  a  "left"  (or  "OUT")  orien¬ 
tation  of  p  to  line  N1N2.  If  the  above  expression  is  false, 
then  the  sign  of  sin  is  less  than  zero  and  p  is  to  the  right  of  the 
line.  This  will  define  a  "right"  (or  "IN")  orientation  of  p  to  the 
line. 


•Note:  This  form  corresponds  to  Ax  mentioned  in  Appendix  B. 
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Note  further  that  if  the  orientation  of  one  endpoint  of  a  segment  is 
"right"  and  the  other  endpoint  is  "left"  then  the  segment  oust  cross 
the  line  at  soae  point,  but  not  necessarily  between  and  N2 . 

C.3  Time  to  Penetration 

Ty  will  be  determined  as  follows: 

Consider  the  example  in  Figure  C-2  where  the  trajectory  segment  is 
defined  by  its  Cusps,  C  -  (Uc,  Vc)  and  P  ■  (Up,  Vp)  and, 
the  polygon  elide  is  determined  by  its  endpoints,  *  (Ui»Vi) 
and  N2  “  (U2,V2).  Note  also  that  Tp  *  t_  -  tc  is  the 
time  to  travel  between  the  cusps. 


The  time  to  intersection  is  defined  with  respect  to  the  distance  to 
the  intersection  point,  d,  as: 


or 

d  -  |S|  Tv 

where  S  is  the  speed  along  the  segment. 

The  total  distance  traveled  during  the  trajectory  segment  is: 
CP  -  |S|  Tp  [C-3] 

By  similar  triangles  (see  Figure  C-2): 


[C-4] 


If  Equations  C-2  and  C-3  are  now  substituted  into  Equation  C-4,  and 
the  velocity  factored  out,  then  the  following  expression  is  obtained 
which  relates  Ty  to  the  distances  a  and  b: 

Ty  a 

Tp  a+b 


C-4 


The  distance  a  Is  then  determined  as:* 
a  ■  |C|  sin  0 


And  the  iistance  b  as: 


b  r  I P I  sin  V 


By  considering  the  cross  product  of  N  to  C: 


|C|  sin  e 


And  the  cross  product  of  N  to  P: 
|T|  sin  V  -  - 


The  following  relationship  is  obtained: 


P  a+b  (NxCH(NxP) 

Ty  can  now  be  expressed  in  terns  of  Tp  and  the  cross  products 
NxC  and  NxP  as: 

(NrC)T 

X  *= - - - 

V  (NxC)+(NxP) 

C.4  Convex  Polygon  Intersections 

The  Convex_Polygon_Inter8ection_Check  (Figure  4-26)  operates  on 
polygons  that  contain  only  convex  angles  between  sides.  This  algo¬ 
rithm  is  very  similar  to  Mixed_Polygon_Intersection_Check  (Figure 
4-27)  which  is  a  more  general  algorithm.  The  convex  case  is  dis¬ 
cussed  separately  here,  since  certain  efficiencies  (not  addressed 
here)  can  be  incorporated  to  enhance  the  performance  of  the  algo¬ 
rithm  on  convex  polygons.  The  algorithm  loops  through  the  sides  of 


•Angles  are  measured  in  a  counter-clockwise  direction. 


the  polygon  to  determine  If  intersections  exist.  A  possible  lnterr 
seetion  is  noted  if  the  orientation  of  a  vertex  does  not  natch  the 
orientation  of  the  previous  vertex  (sequencing  in  a  clockwise 
fashion).  To  find  if  an  intersection  truly  exists,  the  orientation 
of  the  cusps  with  respect  to  the  polygon  side  are  examined.  If  an 
intersection  indeed  exists,  then  the  time  to  penetration  is  cal¬ 
culated  and  recorded  in  the  list  of  intersections  for  the  given 
polygon/ trajectory  segment  pair. 

If  no  intersections  occur,  the  algorithm  checks  to  see  if  the 
segment  is  completely  within  the  polygon.  If  only  one  intersection 
occurs,  the  algorithm  checks  to  see  which  cusp  is  inside  the  poly¬ 
gon.  In  both  cases  the  Included  points  are  added  to  the  intersec¬ 
tion  list.  See  section  C.5  for  more  discussion  on  inclusion/ 
exclusion  of  points  with  respect  to  a  polygon. 

C«3  Mixed  Polygon  Interactions 

Klxed_Folygon_Intersectlon_Checka  (Figure  4-27)  operates  on  polygons 
which- contain  both  convex  and  concave  angles.  The  algorithm  will 
loop  through  the  sides  which  define  the  polygon.  The  orientation  of 
the  polygon  sides  to  the  trajectory  segment  will  be  examined  to 
determine  whether  a  penetration  is  possible. 

To  gain  an  understanding  of  how  the  mixed  algorithm  operates,  a  few 
points  that  must  be  assumed  will  be  presented. 

e  If  any  polygon  is  crossed  by  an  "infinite"  length  line,  the 
"ends"  of  that  line  are  outside  the  polygon  area  (see  Figure 
C-3). 

e  As  a  point  moves  along  this  line,  each  time  it  crosses  a 
polygon  side  its  state  is  altered.  Its  state  varies  between 
IN  or  OUT  of  the  polygon  area. 

e  An  "infinite"  line  crossing  any  polygon  will  cross  an  even 
number  of  sides.  Since  such  a  line  begins  outside  of  the 
polygon  and  ends  outside  of  the  polygon,  an  even  number  of 
crosses  must  have  occurred. 


e  If  a  point  is  within  a  polygon  area,  and  an  "infinite"  line 
is  laid  over  the  point,  the  point  would  cross  an  odd  number 
of  sides  if  the  point  moved  to  either  end  of  the  line.  This 
is  because  its  state  has  been  altered  from  IN  to  OUT. 


•  If  a  point  Is  outside  the  polygon  and  an  "infinite”  line  ia 
laid  over  the  p  lint ,  the  point  would  cross  an  even  number  of 
sides  (or  no  sides)  as  it  moved  to  either  end.  This  is  true 
because  its  staie  (OUT)  has  not  changed. 

It  is  visually  easy  to  sec  if  a  point  is  IN  or  OUT  by  counting  the 
sides  crossed  as  it  mo  'es  towards  an  end,  but  computationally  dif¬ 
ficult.  All  sides  must  be  searched  to  see  if  they  are  crossed  by 
the  line  and  if  they  lie  between  the  point  and  the  chosen  end. 

The  mixed  algorithm  uses  the  above  information  in  a  slightly  dif¬ 
ferent  form.  Instead  of  a  point,  the  trajectory  segment  is  used  and 
an  infinite  vector  is  laid  over  it  (see  Figure  C-4). 

The  infinite  vector  is  called  the  trajectory  path.  In  most  cases 
the  mixed  algorithm  must  search  all  sides  to  see  if  they  have  been 
crossed  by  the  trajectory  path.  If  a  side  is  crossed  by  the  path,  a 
cross  product  is  employed  to  see  if  the  trajectory  path  is  IN  or  OUT 
relative  to  the  particular  side.  (If  the  trajectory  path  actually 
entered  at  the  side,  it  would  Instantly  be  known  that  part  of  the 
path  is  inside  the  polygon. ) 

To  relate  this  back  to  rhe  idea  of  moving  from  a  point  to  the  end  of 
an  infinite  line  (see  Figure  C-4),  an  IN  orientation  would  mean  that 
the  moving  point  was  IN  the  polygon  area  before  it  crossed  the  side 
moving  towards  an  end. 

The  mixed  algorithm  keeps  a  running  sum  of  the  INs  and  OUTs,  where 
IN  ■  +1  and  OUT  ■  -1.  A  final  sum  of  0  means  that  an  even  number  of 
sides  were  crossed  between  the  trajectory  segment  and  either  end  of 
the  trajectory  path.  Therefore,  a  sum  of  0  means  that  the 
trajectory  segment  was  entirely  outside  the  polygon  area.  A  final 
sum  of  +2  means  that  an  odd  number  of  sides  were  crossed  in  either 
direction  and  the  entire  trajectory  segment  is  therefore  inside  the 
polygon  area  (see  Figure  C-5). 

Special  situations  which  can  occur  are  as  follows: 

•  The  trajectory  path  coincides  with  a  polygon  vertex,  but  a 
moving  point  passing  through  the  vertex  would  not  alter  its 
state  of  being  IN  or  OUT  (see  Figure  C-6).  In  Figure  C-6a, 
vertex  Va  coincides  with  the  trajectory  path.  Since  a 
point  moving  through  this  vertex  would  always  remain  outside 
the  polygon,  the  running  sum  should  not  change.  In  Figure 
C-6b  we  have  the  Bame  situation,  but  the  point  never  varies 
from  being  inside  the  polygon  as  it  passes  through  vertex 


The  trajectory  path  coincides  with  a  polygon  vertex,  but  a 
■ovlng  point's  atate  would  be  altered  aa  It  croased  over  the 
vertex  (see  Figure  C-7) .  In  Figure  C-7e,  at  vertex  Vc,  a 
+1  ahould  be  added  to  the  running  sua.  In  Figure  C-7b,  at 
vertex  Vd,  a  -1  ahould  be  added  to  the  sua. 

The  trajectory  path  coincides  with  a  side  of  the  polygon, 
and  like  situation  1,  the  running  sua  should  not  change  (see 
Figure  C-8). 

The  trajectory  path  coincides  with  a  side  of  the  polygon, 
and  like  eltuatlon  2,  the  running  sua  should  change  (see 
Figure  C-9). 


FIGURE  C-9 
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GLOSSARY 


Numbers  In  parenthesis  at  the  end  of  the  definition  refer  to  the 
section  in  which  the  tern  is  first  used. 


AAS 


AS) 

Variable 

A CD  Vector 


Air  Traffic 
Controller 

Area 

AKTGC 

ATC 

Cell 


Advanced  Autonation  Systea  (1.1). 

The  process  of  collecting  environmental  data  and 
storing  it  in  systea  data  bases  (1.5.1). 

The  distance  of  a  converted  fix  on  the  route  froa 
the  first  converted  fix  (2.1.1). 

The  concept  of  sutoaated  en  route  air  traffic 
control  described  in  "The  AERA  Concept”  [12]  (3.4). 

An  AGD  variable  is  an  eleaent  (gradient,  direction 
or  acceleration)  of  the  AGD  Vector  (2.1.3).  (See 
also  "AGD  Vector") 

The  AGD  vector  is  the  3-tuple  (acceleration,  gra¬ 
dient  and  direction)  controlling  the  construction 
of  a  segaent  (2.1.3). 

See  "Controller"  (1.4.1). 


An  area  is  a  second  level  division  of  the  conti¬ 
nental  United  States  Airspace.  Controllers  are 
specially  trained  for  an  area's  airspace,  a  region 
bounded  horizontally  by  a  polygon  and  having  soae 
vertical  extent  (1.4.1).  (See  also  "Center"  and 
"Sector”) 

Air  Route  Traffic  Control  Center  (1.4.1).  (See 
also "Center") 

Air  Traffic  Control  (1.1). 

A  discrete  coapartnent  of  the  wind  grid  (2.1.1). 
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Center 


A  center  Is  the  administrative  headquarters  and  the 
operational  facility  for  control  of  the  first-level 
division  of  the  Continental  United  States  Airspace. 
The  center  controls  a  region  bounded  horizontally 
by  a  polygon  and  vertically  by  the  Center  floor  and 
an  altitude  of  60,000  feet  (1.4.1).  (See  also 
"Area"  and  "Sector") 


Clearance 


A  specially  formatted  order  from  the  controller  to 
the  pilot  which  commands  the  pilot  to  execute  a 
maneuver  (2.1.3). 


Controller 
Converted  Fix 


Converted 

Route 


Third-level  algorithmic  unit  in  the  breakdown  of  an 
automation  function  (1.3).  (See  also  "Subfunction" 
"Element") 

An  en  route  radar  controller  aa  defined  in  (1.4.1). 

A  fir  that  is  a  component  of  the  aircraft  route 
after  Route  Conversion  processing  (1.4.1. 2).  (See 
also  "Fix"  and  "Coordination  Fix") 

The  filed  route  of  flight  as  augmented  in  Route 
Conversion  with  preferred  arrival  routes,  among 
others  (1.5.2). 


Coordination 

Fix 


Element 


Grid  Cells 


A  special  purpose  fix  used  for  a  reference  location 
when  flight  plans  are  transmitted  to  the  next  con¬ 
trol  area  (1.5.2).  (See  also  "Fix"  and  "Converted 
Fix") 

An  aircraft  trajectory  is  represented  as  a  series 
of  points  called  cusps.  The  cusps  are  the  points 
of  possible  AGD  vector  discontinuity  (2.1.2). 

Fourth-level  algorithmic  unit  in  breakdown  of  an 
automation  function  (1.3).  (See  also  "Subfunction" 
and  "Component") 

Federal  Aviation  Administration  (1.1). 

A  named  x,y  location  (1.4. 1.2). 

Discrete  compartments  of  the  wind  grid  (2.1.1). 
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Interface 


NAS 

Mast  Cttap 


fnat  Cusp 


PDL 

madias 

Action  Hat 


Profile 

Inference 

mint 


Interaction  mechanism  provided  by  the  computer 
system  to  translate  human  Input  Into  internal 
format  and  translate  internal  format  into  human 
readable  form  (2.1.2). 

National  Airspace  System  (1.1). 

The  next  position  to  which  the  airerft  route  will 
be  modeled  (2.1.2). 

The  position  to  which  the  aircraft  route  has  been 
modeled  (2.1.2).  (This  point  may  be  at  some  future 
position  In  terms  of  the  current  actual  aircraft 
position. ) 

Program  Design  Language  (1.2  and  Appendix  E). 

A  list  which  contains  planned  actions  which  may 
effect  the  aircraft  trajectory  from  the  past  cusp 
onward  (2.1.3).  (See  also  "Past  Cusp"  and  "Planned 
Action" ) 

A  set  of  planned  actions  for  an  aircraft  (1.5.2). 
(See  also  the  definition  of  "Planned  Action") 

An  Internal  representation  of  a  proposed  change  of 
aircraft  clearance  which  can  be  modeled  Into  the 
aircraft  trajectory  (2.1.2). 

The  geographic  area  over  which  the  Trajectory  Esti¬ 
mation  algorithm  operates.  This  area  Includes  the 
extent  of  an  entire  Air  Route  Traffic  Control 
Center  (ARTCC)  and  also  Includes  a  buffer  area 
(2.1.1). 

A  4-space  position  used  to  Initialize  Trajectory 
Estimation  (1.5.2). 


Sector  A  sector  is  the  third  level  division  of  the  Conti¬ 

nental  United  States  airspace.  A  sector  Is  the 
division  to  which  a  controller  Is  assigned  (1.4.1). 
(See  also  the  definition  of  "Center"  and  "Area") 
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A  segment  la  a  part  of  an  aircraft  trajectory 
repreaented  by  an  laplied  line  between  two  adjacent 
cuapa.  The  gradient ,  direction,  and  acceleration 
of  the  aircraft  are  conatant  acroaa  the  aegaent 
(2.1.2). 

Stimulus 

A  atlaulua  la  one  of  several  flight  path  events 
related  to  a  planned  action  which  initiate  the 
planned  action  processing  component  (2.1.3). 

Subfunction 

The  aecond-level  algorithmic  unit  in  the  breakdown 
of  an  autoaatlon  function  (1.3).  (See  alao 
"Component"  and  "Element”) 

Trajectory 

A  deacrlption  of  an  aircraft 'a  position  in 
(x,y,z,t)  apace,  produced  by  applying  altitude  and 
timing  assumptions  to  the  filed  flight  plan  and 
revising  when  necessary  (1.4. 1.2). 

Vlad  Grid 

A  grid  structure  overlaid  on  the  planning  region  to 
relate  geographic  coordinates  to  wind  speed, 
direction  and  tenperature  at  that  location  (2.1.1). 
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AERA  PDL  LANGUAGE  REFERENCE  S  IK  MARY 


E.l  Overview  of  the  Use  of  AERA  PDL 


The  AERA  Prograa  Design  Language  (PDL)  has  been  created  for  the 
single  purpose  of  presenting  algorithas  In  this  specification 
docuaent.  It  evolves  froa  previous  abba  uses,  and  from  MITRE 
WP-81W552,  "All  About  E,"  October  1981. 

The  description  of  this  appendix  Is  Intended  to  support  readers  and 
users  of  AERA  PDL.  ABBA  pdl  supports  readable,  yet  structured  and 
consistent,  descriptions  of  algorithas. 

AERA  PDL  Features 


e  Relational  data  tables  can  be  defined  and  aanlpulated  by 
constructs  In  the  language. 

e  Bulltin  functions  are  used  to  provide  routine  calculations 
without  showing  all  of  the  detail. 

e  Routines  are  used  to  modularize  logic  paths  and  data  scope. 

e  Indentation  Is  used  to  Indicate  stateaent  grouping, 
statement  continuation,  and  levels  of  nesting. 

e  Routines  explicitly  define  data  or  refer  to  predefined  data. 

AERA  PDL  Statements 


The  types  of  statements  used  In  AERA  PDL  are: 

e  English  language  statements 
e  assignment  statements 
e  routine  declaration  statements 
e  data  manipulation  statements 
e  flow  of  control  statements 

E.2  Elements  of  AERA  PDL 


Keywords 

Keywords  are  words  reserved  for  the  usage  of  AERA  PDL.  Figure 
E-l  presents  all  the  keywords  used  in  the  current  version  of 
AERA  PDL,  grouped  for  convenience. 


routine  construction  keywords 

CALL  END  ROUTINE 

data  reference  keywords 


PARAMETERS  IN 

REFER  TO  GLOBAL  OUT 

REFER  TO  SHARED  LOCAL  INPUT 

DEFINED  IN  GLOSSARY 

data  definition  keywords 

DEFINE  CONSTANT(S) 

DEFINE  VARIABLES  ) 

DEFINE  TABLE(S) 


common  arithmetic  bulltln  function  keywords 


AVG 

MIN 

ABS 

EXP 

COS 

ARCCOS 

Sum 

MAX 

CEIL 

LOG 

SIN 

ARCSIN 

MEDIAN 

FLOOR 

SORT 

TAN 

ARCTAN 

SigMjm 

MOD 

coordinate  geometry  bulltln  function  keywords 

PI ST  DOT  INTERSECTION 

MAGNITUDE  CROSS  INTERPOLATE 

DIRECTION  LINE 

set  bulltln  function  keywords 

UNIQUE  COUNT  CONCAT  BOOL 
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set  operator  keywords 


ihlii 


ON  INTERSECT 


table  Manipulation  keywords 
SELECT  FIELDS 


value  constant  keywords 
TRUE 

comparison  keywords 


FALSE 


flow  of  control  keywords 

IF  ...  THEN  ...  ELSE 
CHOOSE  CASE  ...  WHEN 


return  cofrrr 


NULL 


NOT 

GT 

ja 

OR 

GE 

NE 

AND 

LT 

IS 

IN 

LE 

IS 

NOT  IN 

lutma 


OTHERWISE 


REPEAT  WHILE 
REPEAT  UNTIL 

REPEAT  FOR  EACH  ...  RECORD 
GO  TO 
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The  operators  of  AERA  FDL  are  summarized  in  Figure  E-2. 

The  Assignment  Operator 

•  The  format  of  the  assignment  statement  1b: 

"target"  ■  "expression" 

•  The  target  may  be  any  type  of  data  allowed  by  AERA  PDL. 

•  The  assignment  operator  includes  the  ability  to  fill  a  table 
from  data  contained  in  other  tables.  The  form  of  this  use 
of  the  assignment  operator  is: 

"table_name"  “  "table_ex press ion"  ; 

Bulltin  Functions 

The  bulltin  functions  of  AERA  PDL  accept  either  an  single  value 
or  data  organized  into  an  array.  The  author  of  a  routine  must 
make  it  clear  in  comments  and  text  what  form  of  data  is  being 
processed  by  the  bulltin  function.  Bulltin  functions  are 
listed  in  Figure  E-3. 

E.3  Routine  Construction 

The  order  of  appearance  of  constructs  in  a  routine  is: 

•  rouTINE  —  required 

•  PARAMETERS  —  optional 

e  REFER  TO  GLOBAL  —  optional 

•  REFER  TO  SHARED  LOCAL  —  optional 

•  DEFINED  IN  GLOSSARY  —  optional 

•  DEFINE  CONSTANTS  —  optional 

•  DEFINE  VARIABLES  —  optional 

•  DEFINE  TABLES  —  optional 

•  logic  flow  —  required,  but  will  vary  by  routine. 

•  END  —  required 

Three  of  the  constructs  are  noted  below: 

The  ROUTINE  Construct 

•  The  ROUTINE  construct  names  the  routine. 

•  The  syntax  of  the  ROUTINE  construct  is: 

ROUTINE  "routine_name"  ; 


assignment  operator 

A  ■  B  A  Is  assigned  the  value  of  B 

arithmetic  operators 

A  +  B  A  plus  B 

A  -  B  A  minus  B 

A  *  B  A  times  B 

A  /  B  A  divided  by  B 

A  **  B  A  to  the  power  of  B 

comparison  operators 

A  LT  B  A  Is  less  than  B 

A  LE  B  A  is  less  than  or  equal  to  B 

A  GT  B  A  Is  greater  than  B 

A  GE  B  A  Is  greater  than  or  equal  to  B 

A  EQ  B  A  Is  equal  to  B 

A  MI  B  A  Is  not  equal  to  B 

logical  operators 

NOT  A  The  logical  opposite  of  A 

A  OR  B  Logical  OR  of  A  and  B 

A  AND  B  Logical  JSD  of  A  and  B 

set  operators 

A  INTERSECT  B  The  set  Intersection  of  A  and  B 

A  UNION  B  The  set  union  of  A  and  B 

A  IS  IN  B  A  Is  an  element  of  the  set  B 

A  IS  NOT  IN  B  A  Is  not  an  element  of  the  set  B 
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FUNCTION 


MEANING 


ABS(x) 

ARCCOS(x,y) 

ARCSIN(x.y) 

ARCTAN(x.y) 

AVG(A) 

BOOL(x) 

CEIL(x) 

CONCAT(sl,s2 

COS(x) 

COUNT(A) 

CROSS (vl,v2) 

DIRECTION(pl 

DIST(pl,p2) 

DOI(vl,v2) 

EXP(x) 

FLOOR(x) 


Absolute  value  of  x 

Inverse  cosine  of  the  ratio  of  y  to  x 

Inverse  sine  of  the  ratio  of  y  to  x 

Inverse  tangent  of  the  ratio  of  y  to  x 

Mean  of  the  elements  In  A 

Numerical  equivalent  of  logical  condition: 

1  if  x  Is  TRUE,  0  If  x  is  FALSE 

Smallest  Integer  greater  than  or  equal  to  x 

...,sN)  Concatenation  of  strings  si  through  sN 

Cosine  of  x 

Number  of  elements  of  a  set  A 

Cross  product  of  vectors  vl  and  v2 

p2)  Direction  of  p2  from  pi  in  degrees  from  the 

north;  usually  will  be  expressed  in  degrees 
clockwise  from  true  north 

Euclidean  distance  between  points  pi  and  p2 

Dot  product  of  vectors  vl  and  v2 

e  to  the  x  power 

Greatest  Integer  less  than  or  equal  to  x 

FIGURE  E-3 
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FUNCTION 


MEANING 


INTERFOLATE(a,b,t) 
INTER SECT ION (Ll»L2) 
LINE(pl,p2) 


LOG(x) 

MAGNITUDE(v) 

MAX(A) 

MEDIAN(A) 

MIN(A) 

HOD<xl,i2) 

PROD(A) 

SIGNUM(x) 


SIN(x) 

SQRT(x) 

SPM(A) 

TAN(x) 

UNIQUE(A) 


The  point  (l-t)a+tb 

The  point  of  Intersection  of  the  lines  LI  and 
L2 

Vector  (a,b,c)  corresponding  to  the  line 
ax  +  by  ■  c  which  passes  through  the  points 
pi  and  p2 

Log  of  x  In  base  e 

Length  (l.e.,  non)  of  the  vector  v 

Largest  of  the  eleaents  In  the  set  A 

Median  value  of  the  eleaents  in  set  A 

Smallest  of  the  values  in  set  A 

Reaainder  when  xl  Is  divided  by  x2 

Product  of  the  eleaents  in  A 

Function  yielding  1  If  x  GT  0,  -1  if  x  LT  0, 
and  0  If  x  EQ  0 

Sine  of  x 

Square  root  of  x 

Sun  of  the  eleaents  in  A 

Tangent  of  x 

The  set  A  with  no  duplicate  eleaents 
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The  CALL  Construct 


•  The  CALL  construe  invokes  use  of  another  routine  as  a 
subroutine  and  p&  >es  to  it  the  data  on  which  it  is  to 
operate. 

•  The  syntax  of  the  lLL  construct  is: 

CALL  "routine_n<uie"  (  Mdata_usage_list"  )  ; 

•  The  data  usage  list  in  the  cat.t.  statement  must  match  in 
number  and  data  utilization  (IN,  OUT,  INPUT)  the  PARAMETERS 
statement  of  the  called  routine. 

The  END  Construct 


a  The  END  construct  shows  the  formal  end  of  the  routine. 

a  The  syntax  of  the  END  construct  is: 

END  "routine_name"  ; 

E.4  Data  Definitions 


Data  usage  is  defined  in  the  constructs  placed  at  the  beginning  of 
each  routine. 

The  structures,  or  organization  of  data,  recognizable  to  AERA  PDL 
Include  constants,  atomic  variables,  hierarchically  structured 
variables,  arrays,  tables,  and  field-types.  The  hierarchically 
structured  variables  are  the  same  as  the  structure  variables  of  PL/I. 

Within  a  table,  the  values  corresponding  to  the  definition  of  a 
field-type  are  called  fields  when  they  are  referred  to  individ¬ 
ually.  The  values  for  a  whole  column  of  a  table  (or  a  subset  of  the 
whole  column)  may  be  referred  to  as  a  set  of  fields. 

The  following  data  definition  constructs  appear  in  the  order  shown, 
if  any  are  needed.  The  first  line  of  each  construct  begins  in 
column  1,  aligned  with  the  ROUTINE  construct. 

The  PARAMETERS  Construct 


a  This  construct  provides  usage  information  about  the  data 
that  are  being  provided  by  the  calling  routine  in  the  form 
of  specification  of  read-only  'IN’,  write-only  'OUT',  or 
modification  of  an  existing  value  TlNOUT' . 


The  REFER  TO  GLOBAL  Construct 


The  REFER  TO  SHARED  LOCAL  Construct 


•  This  construct  provides  reference  to,  and  usage  infozaatlon 
for,  data  froa  the  Shared  Local  data  aodel  described  In 
Appendix  A  of  the  specification. 

e  The  syntax  of  the  shared  local  construct  is: 

REFER  TO  SHARED  LOCAL  "data  usage  list"  ; 


The  DEFINED  IN  GLOSSARY  Construct 


e  This  construct  provides  reference  to,  and  usage  lnfonaatlon 
for,  data  froa  a  specially  prepared  Glossary  that  central¬ 
izes  the  definition  of  data  variables  that  are  used  re¬ 
peatedly  within  a  given  function  of  the  algorlthalc 
specification. 

e  The  syntax  of  the  shared  local  construct  is: 

DEFINED  IN  GLOSSARY  "data  usage  list"  ; 


The  DEFINE  CONSTANTS  Construct 


The  DEFINE  VARIABLES  Construct 


•  The  syntax  of  the  DEFINE  VARIABLES  construct  is: 

DEFI?  B  VARIABLES  "variable_definition_block,•  ; 

The  DEFINE  TABLES  Construct 

•  The  syntax  of  the  DEFINE  VARIABLES  construct  is: 

DEFINE  TABLES  "table_definition_block" ; 

E.5  Flow  of  Control  Constructs 

The  IF. ..THEN. ..ELSE  Construct 

•  The  syntax  of  the  .  .THEN. .  .ELSE  construct  is : 

IF  "condition" 

THEN 

"stateaent  block" 

[  ELSE 

”statement_block"  J 
The  CHOOSE  CASE  Cons true t 


•  This  construct  provides  a  choice  of  one  of  several  alterna¬ 
tive  logic  paths  depending  on  the  first  condition  satisfied 
among  the  conditions  specified. 

•  The  OTHERWISE  phrase  is  optional. 

•  The  syntax  of  the  CHOOSE  CASE  construct  is: 

CHOOSE  CASE 

WHEN  "condition"  THEN 
"s  tatemen  t_block" 

[  WHSN  phrases  "repeated  as  necessary  ] 

[  OTHERWISE 

" b  tat ement_block "  ] 

The  REPEAT  WHILE  Construct 


•  The  syntax  of  the  REPEAT  WHILE  construct  is: 

REPEAT  WHILE  "condition"  ; 
"stateoent_block" 

The  REPEAT  UNTIL  construct 

•  The  syntax  of  the  REPEAT  UNTIL  construct  is: 

REPEAT  UNTIL  "con.  ition"  ; 

"statement  block" 
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The  REPEAT  FOR  EACH  RECORD  Construct 


•  This  construct  explicitly  loops  over  all  records  in  table, 
or  the  subset  of  a  table  as  specified  in  a  WHERE  phrase. 

•  The  syntax  of  the  REPEAT  FOR  EACH  construct  is: 

REPEAT  FOR  EACH  "table  name"  RECORD 
I  WtiERE  "condition"  ]“*; 

"statement_block" 

•  Within  the  statement  block  of  this  loop,  the  construct  of 
"table_name"."field_name"  means  only  the  ONE  value  that  is 
associated  with  the  record  for  that  iteration  of  the  loop. 

•  If  it  is  necessary  to  refer  to  entire  columns  of  the  table 
that  is  being  looped  on,  the  correct  form  of  the  reference 
is  ALL("table_name"."field_name").  This  construct  means 
exactly  what  "table_name" . "field_naae”  would  have  meant  if 
the  loop  had  not  been  in  effect. 

The  GO  TO  Construct 

•  The  syntax  of  the  GO  TO  construct  is: 

GO  TO  "label"  ; 

The  FOR... TO...  Construct 


•  The  syntax  of  the  FOR. . .TO. . .  construct  is : 

FOR  "loopjlndex"  -  "initial_value"  TO  "last_value”  ; 
"statement_block" 

E.6  Table  Manipulation  Constructs 
The  SELECT  FIELDS  Construct 

•  This  construct  extracts  data  from  a  table,  or  from  a  collec¬ 
tion  of  tables,  and  makes  it  available  to  the  routine. 

•  The  syntax  of  the  SELECT  FIELDS  construct  is: 

SELECT  FIELDS  [  UNIQUE  ]  [  "field  list"  |  ALL] 

- PROW  "table  naii  list"  ”  - 

[  INTO  "local  variable  name  list"  ] 

I  WHERE  "condition"  ]  “ 

I  ORDERED  BY  "field  name"  ] 

I  RETURN  COUNT  (  "local  variable"  )  ]  ; 


The  INSERT  INTO  Construct 


•  This  construct  allows  a  new  record  to  be  inserted  into  a 
table. 

•  The  syntax  of  the  INSERT  INTO  construct  is: 

INSERT  INTO  "table_nane"  ("field  assignments") 

[  WHERE  “condition"]  ; 

•  All  Insertions  will  preserve  the  assumption  of  no  duplicate 
records  allowed  in  the  table. 

The  UPDATE  IN  Construct 


a  This  construct  allows  existing  records  in  a  table  to  have 
certain  of  their  values  changed. 

e  The  syntax  of  the  UPDATE  IN  construct  is: 

UPDATE  IN  "table  name"  ("field  assignments") 

[  mm  "condition"  ]  j 

The  DELETE  FROM  Construct 


a  This  construct  removes  selected  records  from  a  table. 

a  The  syntax  of  the  DELETE  PROM  construct  is: 

DELETE  FROM  "table_name* 
t  WHERE  "condition"  ]  ; 

E.7  Glossary 

"comparison" 

a  There  are  four  possible  syntaxes  for  the  comparison.  These 
are  not  given  separate  names ,  but  will  all  be  shown  as  if 
they  shared  the  same  element  of  the  language. 

a  The  first  syntax  is  for  arithmetic  comparisons: 

"individual"  GE|LE|GT|Lr  "individual" 

a  The  second  syntax  is  for  general  comparisons: 

"individual"  E&lNE  "individual" 

a  Both  of  these  syntaxes  are  also  valid  if  they  are  used  to 
compare  two  variables  with  the  same  complex  organization, 
for  example  two  vectors  of  the  same  length  or  two  field 
types  from  the  sane  table.  In  this  case  the  result  has  as 
many  answers  as  there  are  elements  in  the  compared  variables. 


•  The  third  syntax  Is  for  arithmetic  comparisons: 

"individual"  GE|LE|GT|LT  ANY I  ALL  "set" 

s  The  fourth  syntax  is  for  general  comparisons: 

"individual"  IS  IN I IS  NOT  IN  "set" 

•  The  latter  two  syntaxes  are  used  to  qualify  an  Individual 
based  on  any  value  in  a  set  of  values. 

"condition" 


•  The  syntax  of  the  condition  is: 

"comparison"  [ AND  1 AND  NOTIorIqR  NOT  "comparison"] 

•  The  optional  part  of  this  syntax  can  be  repeated  as  often  as 
required. 

"constant  definition  block" 


•  The  content  of  the  constant  definition  block  is  three 
columns:  the  constant  names,  the  constant  values,  and  the 
constant  descriptions. 

•  The  constant  names  are  aligned  in  a  column  3  spaces  Indented 
from  the  DEFINE  CONSTANTS  line. 

•  The  other  two  columns  are  aligned  as  convenient ,  so  that 
there  la  no  visual  overlap  between  the  columns. 

"data  usage  list" 

e  A  routine  must  declare  the  type  of  use  for  all  of  its  data 
that  are  known  outside  the  routine. 


e  The  three  types  of  use  are:  read  only  (IN),  create  (OUT), 
and  modify  an  existing  copy  (INPUT). 

e  The  format  of  a  data  usage  list  is: 

"variablejname"  "usage_type",  ... 

•  An  example  of  the  format  for  data  usage  list  is: 
An_Input_Parameter  IN,  A_LOCAL_TAHLE  INPUT 

"expression" 

e  Variables  may  be  formed  implicitly  in  expressions  without 
being  separately  named  or  defined. 


•  Expressions  are  combinations  of  defined  variables  with  the 
operators  and  bulltlng  functions  of  AERA  PDL. 

•  In  an  expression,  the  Implicit  variable  output  from  any 
builtln  function  may  be  used  as  the  input  to  any  other 
bulltin  function  or  operator. 

e  An  expression,  when  fully  evaluated,  yields  one  variable. 

"field  assignments" 

•  This  term  only  appears  in  statements  referring  to  exactly 
one  table:  INSERT  and  UPDATE. 

s  The  form  of  the  term  is  a  comma-separated  list: 
"fleldjssslgnment",  ... 

e  The  form  of  a  single  assignment  is: 

"fleld_name"  -  "value_expression" 

•  In  this  tern  the  fieldjoames  do  not  have  to  be  qualified  by 
the  table  name  (that  isTgiven  In  the  statement). 

"table  definition  block" 


e  Three  types  of  definition  are  made  In  this  block:  table  defi¬ 
nitions,  field-type  definitions,  and  AGGREGATE  definitions. 

e  Table  definition  lines  are  formatted  as: 

"tablejnaae"  "table_deflnition" 

s  Field-type  definitions  lines  are  formatted  as: 

"field_nane"  "field_definition" 

s  Aggregate  definitions  are  formatted  as: 

"aggregate_name"  AGGREGATE  ("field_name_llst") 

•  Fields  will  contain  only  atomic  (single-valued)  variables. 

e  Aggregates  may  be  used  so  that  a  program  can  manipulate 
multiple  fields  in  one  statement  when  it  makes  sense  to  do 
so. 

"table-expression" 

e  Tables  may  be  used  implicitly  In  assignments  or  comparisons 
being  separately  named  or  defined . 
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•  A  table  expression  is  either  a  table  name  or  a  SELECT  state¬ 
ment  specifying  the  contents  of  the  Implicit  table. 

"table  name" 


e  Generally,  this  Is  just  the  name  of  a  table. 

e  In  a  few  statements,  there  is  a  syntax  that  allows  a  user  to 
define  a  synonym  and  use  it  In  the  rest  of  that  statement. 
The  Intent  of  this  option  is  to  allow  shorter  where  clauses 
that  are  easier  to  read.  The  format  of  the  synonym  refer¬ 
ence  is: 

"exlsting_table_name"  (  "synonym"  ) 

e  The  statements  that  allow  this  use  are  those  that  have  the 
where  clause:  SELECT,  INSERT,  DELETE,  UPDATE,  and  REPEAT. 

"variable  definition  block" 


e  The  content  of  the  variable  definition  block  is  two  columns: 
variable  names  and  variable  descriptions. 

e  Align  variable  names  In  a  column  that  Is  Indented  3  spaces 
from  the  DEFINE  VARIABLES  line. 

e  Align  variable  definitions  In  a  column  as  convenient;  when  a 
structure  element  Is  defined,  both  the  variable  name  and  the 
variable  definition  should  be  Indented  three  spaces  from  the 
name  and  definition  of  the  next  higher  level  variable. 

e  Three  types  of  variables  may  be  defined  In  this  block: 
atonic  variables,  arrays,  and  structured  variables. 

e  Each  element  variable  is  described  by  a  line: 

"variable_name"  "variablejiefinition" 

•  Each  array  variable  Is  described  by  a  line: 

"variable_name "  ("dimensions")  "variablejdefinition" 

e  Each  structured  variable  Is  described  by  multiple  lines,  one 
line  per  lowest  level  element,  and  one  line  for  each  named 
level  of  grouping/structure,  with  Indentation  levels  used  to 
Indicate  the  grouping. 


e  The  names  of  subordinate  elements  of  a  structured  variable 
are  named  in  all  lower  case  letters. 


•  The  use  of  complex  structured  variables  Is  not  encouraged; 
one  reasonable  use  for  them  Is  to  receive  the  values  of 
AGGREGATES. 

E.8  Other  Uses  and  Conventions 

Use  of  Special  Characters  In  AERA  PPL 

•  Parentheses  are  used  for  grouping  statements  and  setting  o_f 
special  parts  of  the  constructs. 

e  Semicolons  are  used  as  statement  terminators. 

•  Colons  are  used  to  terminate  labels. 


•  Underscore  Is  used  to  separate  words  In  multi-word 
identifiers. 

•  The  symbols  *+' ,  and  '/'  are  used  as  arithmetic 

operators. 

•  The  pound  sign  Is  used  as  a  comment  delimiter,  for 

beginning  and  end  of  each  comment  line. 

•  Commas  are  used  as  separators  In  lists  of  operands. 

•  Periods  are  used  to  separate  fully  qualified  names. 

Naming  Conventions 

•  Keyword  Identifiers  use  only  uppercase  letters  and  are 
underlined.  They  are  the  only  underlined  Identifiers  In  the 
PDL. 

e  Table  Identifiers  from  the  relational  data  base  also  use 
only  uppercase  letters. 

e  AGGREGATE  Identifiers  for  combinations  of  fields  use  no 
uppercase  letters. 

e  References  to  fields  In  a  table,  used  in  the  normal  course 
of  reference  In  AERA  PDL,  will  be  fully  qualified  by 
Including  the  table  name. 


Other  Identifiers 


•  Identifiers  for  constants,  routines,  labels,  arrays,  and 

- »*wa*ucad  ^^ahlas  are  all  be  named  using 

word-initial  capitals. 

•  For  hierarchically  structured  variables,  all  of  the  sub¬ 
ordinate  elements  within  the  structure  use  only  lowercase 
letters. 

a  For  hierarchically  structured  variables,  all  references  to 
the  subordinate  elements  in  the  structure  will  be  in  fully 
qualified  form  using  separate  Identifiers. 

•  Global  data  and  shared  local  data  can  include  both  tables 
and  parameters.  Hie  individual  parameters  are  named  using 
word-initial  capitals. 

Use  of  the  Formal  Constructs  in  ABBA  PDL  Statements 


a  Statements  may  use  formal  constructs  or  clear  English 
descriptions  to  specify  the  intended  test  or  action. 

a  Any  AERA  PDL  statement  is  terminated  by  a  semicolon, 
including  any  English  statement  outBide  of  a  comment. 

a  Below  the  level  of  statement,  some  statements  have  a  finer 
organization  in  terms  of  "phrases'*,  usually  occupying  a  line 
per  phrase  and  indented  one  level  from  the  first  line  of  the 
original  statement. 

Statement  Organization 

a  Indentation  is  used  to  indicate  statement  grouping, 

statement  continuation,  and  levels  of  nesting. 

a  Any  statement  may  have  a  label  starting  in  column  1. 

a  Continuation  lines  are  indented  three  spaces  from  the 
original  line  of  the  statement. 

a  Comments  are  used  as  needed,  bracketed  by  the  special 
character  '#'. 
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